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CHAPTER  1  -  INTRODUCTION 


The  goal  of  this  research  is  to  propose  a  framework  for  enhancing  the  use 
of  Computer  Supported  Cooperative  Work  (CSCW)  based  tools  and  other 
enabling  technologies  to  improve  decision-making  processes  in  a  product 
development  environment  Specifically,  the  framework  has  been  targeted  for 
application  to  decisions  typically  made  in  the  “concept  development”  phase  of 
product  development. 

The  framework  research  focuses  in  two  core  areas  -  implementation  of 
CSCW  and  related  system  tools  supporting  the  product  development  process 
and  usage  of  fielded  systems  in  product  development  activities.  Some  of  the  key 
areas  addressed  within  the  framework  are  summarized  below 

•  Implementation  of  a  hierarchically-based  CSCW  architecture  for 
managing  all  data  and  aspects  of  the  concept  development 
process. 

•  Leverage  the  use  of  past  decision  data  within  concept  development 
activities. 

•  Organization  of  data  elements  baselined  around  a  robust  product 
development  process. 

This  report  describes  in  detail  the  core  elements  that  contribute  the 
framework  as  well  as  a  prototype  architecture  developed  to  support  the  research 


2 


Findings  from  a  field  study,  where  the  prototype  architecture  was  applied  to  a 
concept  development  problem,  will  also  be  presented. 
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MOTIVATION 


The  motivation  of  this  research  is  by  optimizing  the  entire  process  of 
deploying  and  applying  computer  tools  targeted  at  product  development 
purposes,  a  more  robust  information  set  can  be  presented  to  an  end  user  to 
contribute  to  reducing  elements  of  uncertainty  inherent  with  concept 
development  decision  making  activities 
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PROBLEM  DESCRIPTION 


Throughout  all  product  development  activities,  decision  making  remains  a 
cornerstone  activity  affecting  virtually  every  aspect  of  the  process  The 
challenge  of  any  product  development  organization  is  to  ensure  consistent, 
timely,  and  complete  information  is  provided  to  decision  makers  to  allow  for 
faster,  more  accurate  and  overall  improved  decision  making.  Within  product 
development,  decisions  are  typically  made  by  individuals  or  groups  functioning  in 
areas  of  design,  engineering,  production,  or  finance  [1]. 

Bringing  new  products  to  market  is  a  relentless  task  due  to  competitive 
and  technological  pressure  being  exerted  from  outside  organization  boundaries 
as  well  as  constraints  on  time  and  other  resources  originating  from  within  an 
organization.  Despite  research  and  advances  put  forth  through  formalized 
product  development  processes,  CSCW  tools,  and  other  technologies,  the 
process  of  bringing  a  product  from  concept  to  market  has  not  become  any  less 
complex  While  few  organizations  can  fully  influence  all  variables  affecting 
product  development,  many  are  attempting  to  identify  ways  to  maximize 
resources,  in  part  through  better  decision  making. 

Problems  attributed  to  product  development  decision  making  are  nowhere 
more  relevant  than  in  the  concept  development  phase  as  referred  to  by  Ulrich 
and  Eppinger  [2],  where  many  key  decisions  influencing  the  direction  and 
outcome  of  the  product  are  made  Unfortunately,  this  is  also  a  time  where 
information  related  to  the  product  development  cycle  is  at  its  most  nebulous, 
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especially  in  the  case  of  new  product  development.  Consider  the  following 
examples  where  decisions  made  during  product  development  resulted  in 
adverse  situations’ 

•  An  electronic  equipment  manufacturer  was  hit  hard  when  a 
competitor  introduced  a  group  of  products  incorporating  newer 
digital  technology.  The  newer  technology  enabled  components  to 
operate  as  part  of  an  integrated  system  networked  with  other 
equipment  Although  the  manufacturer's  management  was  not 
ignorant  of  the  capabilities  of  advanced  digital  technologies,  it  was 
blind-sided  by  the  competitor  because  it  had  not  realized  the 
importance  of  making  a  decision  about  whether  or  not  to 
incorporate  newer  digital  technology  into  its  products.  [3] 

•  In  the  1990's,  Vitek,  Inc.  was  a  Houston-based  manufacturer  of 
medical  products,  including  a  jaw  implant  for  TMJ  (temporo¬ 
mandibular  joint  pain)  patients  characterized  as  chronic  pain 
sufferers  Oral  surgeons  implanted  the  devices  in  approximately 
30,000  patients.  Of  this  patient  base,  about  500  filed  product 
liability  lawsuits  over  a  five-year  period,  alleging  a  number  of 
problems  with  the  implants.  Though  many  oral  surgeons  backed 
the  product  and  a  high  percentage  of  patients  have  reportedly  been 
helped,  the  crescendo  of  litigation  hounded  Vitek  into  Chapter  7 
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bankruptcy  and  a  U.S.  Food  and  Drug  Administration  mandated 
recall  of  the  Vitek  TMJ.  [4] 

•  A  major  electronics  company  identified  an  exciting  new  market 
opportunity  and  launched  a  team  to  develop  the  product.  Soon 
after  the  project  started,  focus  began  to  drift  Several  important 
design  alternatives  were  identified,  but  a  decision  was  needed  to 
select  a  concept  to  move  forward.  Several  months  passed  without 
a  final  decision  Because  a  decision  could  not  be  made  regarding 
the  initial  functionality  of  the  first  product  release  in  a  timely 
manner,  product  entry  was  delayed  by  several  months.  By  the  time 
the  product  was  released,  delays  in  decision-making  proved  to  be 
devastating  as  a  competitor  beat  the  company  to  market. [3] 

These  three  cases  illustrate  examples  where  poor  choices  made  within 
the  development  cycle  resulted  in  substantial  downstream  product  issues.  While 
the  qualifiable  issues  within  these  products  came  down  to  factors  related  of 
timing,  quality,  or  market  acceptance,  a  root  cause  issue  among  all  three  cases 
can  be  attributed  to  how  decisions  were  made  against  levels  of  uncertainty  In 
all  cases,  decision  makers  could  have  benefited  from  additional  information  that 
may  have  influenced  the  outcomes  in  different  ways. 

As  previously  mentioned,  information  used  for  decision  making  during 
concept  development  is  typically  at  its  most  nebulous,  especially  in  the  case  of 
new  product  development.  Decisions  made  during  concept  development  contain 
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some  level  of  uncertainty  which  can  be  attributed,  in  part,  to  sources  identified 
below; 


•  Overall  Market  Conditions  -  Although  product  creators  attempt  to 
“simulate”  future  customer’s  wants  and  needs  [5]  through  analysis 
and  forecasting  [2],  factors  such  as  economic  conditions, 
environmental  conditions  [5],  competitors,  or  other  social  events 
may  adversely  affect  the  acceptance  of  the  product  in  the 
marketplace 

•  Technological  Changes  -  Fast-evolving  advances  in  technology 
may  render  a  new  product  obsolete  upon  introduction.  Product 
developers  are  constantly  challenged  with  trying  to  design  products 
with  a  goal  in  mind  that  neither  makes  it  technologically  obsolete 
nor  dependent  on  an  emerging  technology  that  is  too  new  for 
practical  application.  [6] 

•  Human  Aspect  -  “To  Err  Is  Human”  [7]  Decision  makers  are 
human  and  are  fallible  to  unknowns  Decisions  are  typically  based 
on  an  analysis  of  information  available  on  the  problem  as  well  as 
personal  perceptions,  preferences,  and  knowledge  that  is  gained 
from  experience.  Unfortunately,  knowledge  and  perspective  that 
one  decision  maker  may  have  does  not  readily  transfer  to  other 
decision  makers  Workers  change  jobs  frequently,  and  rarely  is 
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knowledge  retained  at  a  level  to  allow  for  replacements  to  fully 
understand  complex  decision  environments 

With  a  hypothesis  that  uncertainty  (as  related  to  any  number  of  factors) 
affects  concept  development,  some  improvements  in  overall  development  cycles 
can  be  attributed  to  the  evolution  and  expansion  of  computer  tools  allowing 
information  to  be  managed  and/or  processed  in  new  ways  Toyota’s  world  class 
product  development  system  is  based  on  a  balance  of  streamlined  processes 
and  technology  working  to  create  a  lean  environment  [8].  Computer 
technologies  such  as  CSCW  and  the  Internet  have  transformed  how 
organizations  collaborate  by  linking  cross-functional,  distributed  teams  with  a 
common  information  base.  General  Motors  is  an  example  of  a  product 
development  organization  now  producing  cars  developed  collaboratively  over 
multiple  continents  [9]. 

However,  despite  improvements  brought  forth  by  the  use  of  collaborative 
computer  technologies,  uncertainty  in  decision  making  remains  a  concern  to 
product  developers.  In  some  cases,  computer  systems  deployed  to  improve 
information  processing  in  product  life  cycles  failed  to  deliver  intended  benefit  [10] 
[11],  including  situations  where  the  collaborative  information  system  has  become 
little  more  than  an  electronic  replacement  to  paper-based  file  systems  -  a 
"collector*  of  legacy  data  subsequently  not  utilized  in  a  manner  which  could 
influence  organizational  development  cycles  [12]. 
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RESEARCH  QUESTION 


Despite  tremendous  resources  spent  on  deploying  computer  systems  to 
provide  users  access  to  a  comprehensive  information  set,  the  activity  of  decision 
making  for  product  concept  development  remains  an  effort  rife  with  complexity 
and  risk.  Simply  put,  what  can  be  done  to  optimize  development-focused 
computer  tools  to  allow  improvement  by  reducing  levels  of  uncertainty  in  concept 
development  based  decision-making? 


10 


OBJECTIVES 

In  many  ways,  the  basis  for  addressing  the  research  question  translates 
into  an  optimization  process  for  based  on  two  principles: 

•  Locating  the  uhghtn  information  needed  to  make  decisions.  The 
inability  to  locate  information  in  organizational  computer  systems 
can  be  time  consuming  and  costly.  In  some  cases,  decision 
makers  feel  they  do  not  have  access  crucial  information  they 
should  have  -  and  know  exists  -  due  to  limitations  with  existing 
computer  tools  and  supporting  processes  [13]  In  other  cases, 
decision  makers  use  free  form  searches  in  an  attempt  to 
discovered  information  they  think  may  exist  which  could  support 
their  needs  -  “if  we  only  knew  what  we  know”  [1 3]. 

•  Retaining  and  transforming  information  for  future  decision-making 
The  practice  of  capturing  lessons  learned  -  knowledge  intended  to 
help  educate  and  aid  in  making  future  decisions  -  is  usually  best 
formalized  either  in  “project  notebooks”  or  after  action  reviews 
While  lessons  learned  information  is  captured  in  computer 
systems,  it  is  typically  not  stored  or  linked  in  a  manner  allowing  it  to 
be  readily  applied  to  future  decision  making  activities.  Therefore,  a 
goal  will  be  to  transform  “static”  information  such  as  decision 
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history  and  concept  artifacts  into  "dynamic"  data  sets  that  can  be 
leveraged  by  decision  makers 

With  this  context  in  mind,  the  two  main  research  objectives  can  be 
succinctly  stated. 

1  To  put  forward  an  approach  for  creating  and  utilizing  a  CSCW 
architecture  with  the  aim  of  reducing  decision  uncertainty  in  the 
concept  phase  of  product  development  activities 
2.  To  describe  how  data  points  harvested  from  past  decisions  can 
contribute  toward  and  impact  future  concept  development  decision 
making  activities. 
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EXPECTED  CONTRIBUTIONS 

Identification  of  a  senes  of  steps  covering  both  implementation  and  usage  for 

optimizing  a  CSCWsystem  to  benefits  decision  makers. 

As  mentioned,  the  focus  of  the  framework  includes  elements  for 
application  toward  implementation  ("pre-production")  and  usage  (“production”). 
Many  system  optimization  approaches  focus  on  an  "either...  or"  strategy.  While 
each  element  within  the  framework  can  be  leveraged  in  a  “stand  along"  context, 
the  combination  of  the  elements  together  is  intended  to  have  a  greater 
aggregate  effect  on  a  CSCW  system  designed  to  support  concept  development 
activities  than  if  applied  individually.  Finally,  the  framework  is  constructed  to  be 
robust  enough  for  continued  application  as  computer  technology  evolves. 

Introduction  of_  the  “Need-Decision-Result"  [ NDR )  relationship  for  extracting 

storing,  and  reusing  decision-related  data 

While  some  key  decision  details  are  encompassed  within  the  “lessons 
learned"  realm  of  archived  information,  the  use  of  "purely  historical"  decision  data 
has  not  traditionally  been  positioned  as  a  valued  commodity  for  aiding  future 
product  development  decision  making  In  some  applications,  decision 
information  becomes  a  checkpoint  event  with  output  relegated  to  indefinite 
storage  with  no  further  purpose  then  to  serve  an  occasional  audit  or  report.  By 
capturing  key  elements  of  a  decision  having  relevance  to  future  decision  makers, 
combined  with  narrative  information  supporting  both  “before"  (the  needs)  and 
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“after”  (the  results)  aspects  of  the  decision,  decision  makers  can  benefit  from  a 
tangentially  unique  data  set. 
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CHAPTER  2  -  BACKGROUND 

This  chapter  describes  the  results  of  an  information  search  conducted  to 
understand  key  foundational  concepts  from  the  general  body  knowledge 
preceding  this  research  effort.  The  emphasis  on  the  search  was  to  locate 
appropriate  literature  that  meets  one  or  more  of  the  following  criteria: 

•  Contributes  relevant  ideas  supporting  the  context  of  the  research. 

•  Takes  an  applied,  practical  approach  to  the  subject  matter  rather 
than  purely  theoretical  approach 

•  Describes  case  studies  or  examples  related  to  applicable 
development  practices  leveraging  collaborative  technologies 

The  nature  of  the  research  draws  from  several  well-documented 
technologies,  including  product  development  processes,  CSCW  systems 
(including  workflow-based  processing  and  system  integration),  decision  making, 
content  search  and  filtering  techniques,  and  risk  assessment.  Although  many  of 
these  topics  have  been  well-researched  through  the  years,  substantial 
opportunity  exists  to  contribute  new  ideas  to  the  literature  as  the  momentum  of 
technology  advance  drives  the  evolution  of  these  foundational  concepts 
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PRODUCT  DEVELOPMENT  PROCESSES 

Product  development  processes  are  a  set  of  steps  and  phases  describing 
a  standard  means  by  which  a  company  repetitively  converts  embryonic  ideas  into 
salable  products  or  services  [14).  The  study  of  product  development  processes 
has  generated  substantial  interest  as  a  research  subject  for  academia  and  a 
strategic  asset  for  companies  engaged  in  delivering  products  to  consumers. 
Globalized  marketplaces,  combined  with  the  rapid  evolution  of  the  modern 
information  age  (in  particular,  the  rise  of  the  World  Wide  Web)  has  created  the 
most  challenging  environment  for  product  development  in  history  [15] 

Over  the  past  decade,  several  important  methodologies  detailing  the 
functions  involved  with  developing  products  have  been  put  forth  [2][5][16]  While 
each  methodology  approaches  the  product  development  process  somewhat 
uniquely,  all  share  important  elements. 

•  The  need  for  an  integrated,  cross-functional  team  working 
collaboratively  to  share  information  [16] 

•  The  ability  for  a  product  development  team  to  draw  upon 
organizational  core  competencies  to  help  create  new  products  [17] 

•  An  infrastructure  supporting  team  collaboration  across  barriers  of 
time,  distance,  and  cultural  differences  [16] 

•  An  organization  flexible  enough  to  adapt  to  changing  conditions 
and  circumstances  [18] 
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One  of  the  more  influential  and  comprehensive  product  development 
process  frameworks  has  been  developed  by  Karl  Ulrich  and  Steven  Eppinger. 
The  process,  formally  called  the  Product  Design  and  Development  (PDD) 
process,  divides  the  numerous  activities  of  product  creation  into  six  major 
phases  -  planning,  concept  development,  system-level  design,  detailed  design, 
testing  and  refinement,  and  production  ramp-up  [2],  A  summary  of  the  PDD 
process  is  provided  in  Table  2.1 


Phase 

Title 

Description 

Activities 

Phase  0 

Planning 

“Pre-Project"  activities 
laying  groundwork  for 
project 

-  Technology  review 

-  Marketing  Objectives 

-  Project  Mission  Statement 

Phase  1 

Concept 

Development 

Concepts  selected  for 
further  development  and 
testing 

-  Marketing  targets 

-  Concept  Descriptions 

Phase  2 

System-Level 

Design 

Definition  of  Product 
Architecture 

-  Decomposition  of  Product 
into  Subsystems  and 
Components 

-  Functional  Specifications 

Phase  3 

Detail  Design 

Complete  Specification 
of  Product 

-  Detailed  Geometry  and 
Specifications 

-  Material  Identification 

-  Tooling  Designs 

-  Controlled  Documentation 

Phase  4 

Testing  and 
Refinement 

Construction  and 
Evaluation  of  Pre- 
Production  Versions 

-  Alpha  and  Beta  Prototypes 

-  Reliability  Testing 

-  Design  Changes 

Phase  5 

Production  Ramp- 

Up 

Final  Release  and 
Production  of  Product 

-  Workforce  Training 

-  Pilot  Production  Runs 

Table  2.1  Major  Phases  of  the  PDD 


Within  the  PDD,  phases  are  linked  to  one  another  as  outcomes  from  one 
activity  become  inputs  to  others  A  representation  of  the  entire  PDD  model  is 
provided  in  Figure  2  1  [2] 
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Figure  2.1  The  Product  Design  and  Development  Process 


Although  each  phase  of  the  PDD  represents  an  important  step  in  the 
formation  of  a  product,  it  is  within  the  “Concept  Development"  phase  where  a 
great  deal  of  momentum  for  research  interest  is  focused  [5].  It  is  in  the  concept 
development  phase  where  many  critical  decisions  affecting  the  entire 
development  spectrum  are  made  as  raw  ideas  are  translated  into  product 
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concepts  These  activities  and  critical  decisions  made  Uup  front"  are  referred  to 
as  being  at  the  top  of  the  “product  development  funnel”  [16] 

Within  the  Ulrich  and  Eppinger  model,  the  concept  development  phase 
contains  six  activities  where  the  target  market  is  defined,  alternative  product 
concepts  are  generated  and  evaluated,  and  one  or  more  concepts  are  selected 
for  further  development  The  six  activities  of  the  concept  development  phase  are 
summarized  below. 

•  Identifying  Customer  Needs:  Understand  the  needs  of  the 
customer  and  communicate  to  development  teams. 

•  Establishing  Target  Specifications:  Translation  of  customer  needs 
into  technical  terms  representing  "goals"  of  the  development  team. 

•  Concept  Generation:  Explore  the  space  of  product  concepts  to 
satisfy  customer  needs 

•  Concept  Selection.  Analysis  of  product  concepts  leading  to  the 
identification  of  an  optimal  (or  promising)  concept. 

•  Concept  Testing :  Activities  to  determine  if  customer  needs  have 
been  met  and  assess  the  market  potential  of  the  product 

•  Setting  Final  Specifications:  Commitment  to  specific  values  and 
metrics. 

Input  to  these  activities  includes  product  planning,  economic  analysis, 
benchmarking,  modeling,  and  prototyping  Information  used  for  decision-making 
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in  the  concept  development  phase  of  the  PDD  is  generated  through  contributions 
from  a  multidisciplinary  team  representing  all  major  functions  in  the  organization, 
including  marketing,  design,  and  manufacturing  Standard  information  types 
provided  by  contributors  include  customer  data,  market  intelligence,  design  data, 
and  preliminary  engineering  analysis  [2].  Additionally,  mapping  product  planning 
attributes  to  manage  product  portfolios  can  help  decision  makers  understand  the 
implications  of  product  development  decisions  [19]. 

What  separates  Ulrich  and  Eppinger’s  Product  Design  and  Development 
process  from  others  is  the  depth  of  detail  provided  from  cross-functional 
participation,  which  lends  itself  for  the  broad,  managed  inputs  which  are 
important  to  this  research  framework.  In  particular,  information  in  the  front-end 
phases  used  to  drive  decisions  and  activities  is  at  its  most  nebulous,  or  “fuzzy" 
[18]  [20],  due  in  part  to  uncertainties  that  have  been  attributed  to  future  market 
conditions  [21],  technological  advances  and  shrinking  product  life  cycles  [6],  or 
other  factors  that  may  be  related  to  organizational  or  environmental  changes 
Therefore,  the  goal  of  the  early  phases  of  product  development  is  to  emerge  with 
a  solid,  comprehensive  product  concept  [1]  based  on  the  information  produced 
by  the  cross-functional  product  team. 

Of  relevance  to  this  research  is  literature  related  to  product  development 
aimed  at  process  description  or  problem  solving  techniques,  lansiti  et.  al.  [15] 
described  a  “flexible”,  concurrent  approach  to  product  development  citing 
software  development  projects  as  “primary  advocates"  of  the  process.  Stein  et. 
al.  [16]  provided  a  good  summary  of  product  development  activities  similar  to  the 
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Ulrich  and  Eppinger  process  and  introduced  the  term  “product  development 
funnel”  as  applied  to  early  concept  generation  and  planning.  Recent  literature 
focuses  on  better  decision-making  in  the  early  phases  of  New  Product 
Development  (NPD).  Herrmann  et  .al  [1]  described  the  product  development  in 
terms  of  decisions  rather  than  phases.  Tsinopoulos  et  al.  [22]  expanded  on  the 
role  of  decision-making  in  product  development  by  advocating  a  three-stage 
approach.  Jetter  [5]  proposed  use  of  Kosko’s  Fuzzy  Cognitive  Maps  (FCM) 
approach  linking  requirements,  technologies,  and  components  to  help  in 
developing  product  concepts. 

In  recent  years,  a  great  deal  of  interest  on  product  development  activities 
has  been  focused  on  the  Japanese  automaker  Toyota  Long  cited  as  the  leader 
of  PDD  in  automotive  practices,  the  Toyota  product  development  system 
represents  the  best  example  of  the  incorporation  of  "lean  development".  The 
concept  of  “lean”  reached  prominence  in  the  1990’s  with  Womack  et  al  [23] 
description  of  the  Toyota  development  environment  which  focused  on  “first-time” 
quality,  waste  minimization,  continuous  improvement,  flexibility,  and  long-term 
supplier  relationships.  One  of  the  first  detailed  analysis  of  the  Toyota  product 
development  environment  was  provided  by  Morgan  [24],  which  was  later 
enhanced  by  Morgan  and  Liker  [8].  Kennedy  also  provided  substantial  context 
on  the  application  of  the  Toyota  system  into  a  typical  US-based  automotive 
environment  [25], 

In  1999,  Monplaisir  [26]  proposed  an  Integrated  Product  Design  and 
Development  (IPDD)  CSCW  architecture  based  on  using  online  decision-making 
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tools,  collaboration  workgroups,  and  Web-based  processing.  Incorporating 
earlier  research  by  Monplaisir,  Riordan,  and  Benjamin  [27],  where  the  use  of 
CSCW  architectures  was  applied  to  agile  cell  manufacturing,  the  IPPD  was 
targeted  directly  at  the  concept  and  design  phases  of  product  development.  In 
2002,  using  the  IPDD  as  a  foundation,  Monplaisir  focused  on  the  impact  of 
decision-making  by  introducing  the  Multiple  Criteria  Decision  Making  (MCDM) 
model  [28].  The  MCDM  employs  a  clustered  neural  network  model  to  aggregate 
preferences  and  reduce  the  complexity  of  decisions  in  a  CSCW  environment 
Using  ANOVA  validation,  the  MCDM  showed  statistically  significant  difference  in 
time  required  for  decision-making  in  relation  to  overall  quality  of  work 

Several  practical  problem  solving  techniques  for  product  development 
were  identified  in  the  literature.  Sosa  et.  al.  [29],  Eppinger  et.  al.  [30],  and  Huang 
[31]  all  described  product  development  in  terms  of  a  flexible,  modular  product 
architecture  Nepal  et  al.  [32]  described  a  framework  for  multi-objective 
optimization  of  product  architecture  A  closely  related  approach  generally 
applied  to  product  development  in  order  to  group  dependencies  and  map 
sequences  is  the  Design  Structure  Matrix  (DSM)  [33],  Whitney  et.  al.  [34],  Dong 
et.  al  [35],  Salhieh  [36],  and  Yassine  et.  al  [37]  [38]  each  provided  detailed 
examples  of  DSM  in  product  development  activities. 
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COMPUTER  SUPPORTED  COOPERATIVE  WORK  (CSCW) 

First  coined  in  the  1980’s  [39],  Computer  Supported  Cooperative  Work 
(CSCW)  systems  have  emerged  as  a  key  component  supporting  business 
activities  The  roots  of  CSCW  can  be  traced  decades  earlier  when,  in  1945, 
Vannevar  Bush  called  on  scientists  to  consider  how  to  make  the  accumulating 
body  of  human  knowledge  more  accessible  to  people  while  offering  the  first 
glimpses  how  “machines"  can  be  used  for  storing  and  sharing  information  [40] 
CSCW  tools  provide  a  technological  solution  for  organizations  to  base  distributed 
information  sharing,  retention,  and  process  functions.  Greif  (1988)  included 
applications  supporting  CAD/CAM,  office  systems,  joint  authorship  tools,  and 
project  management  in  the  general  definition  of  CSCW  [41]  A  reason  for  the 
continued  success  of  CSCW  tools  is  the  ability  to  offer  true  collaboration  across 
the  time  and  space  continuum. 

As  described  by  Monplaisir  [28],  successful  CSCW  systems  encompass 
the  following  characteristics: 

•  Interaction  capability  in  either  synchronous  or  asynchronous  mode. 

•  Coordination  of  tasks  to  be  performed  by  members  of  a  team. 

•  Distribution  capabilities  to  enable  interaction  from  remote  locations. 

•  Accessibility  and  sharing  of  data  among  participants 
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Information  on  CSCW-based  processing  is  prevalent  in  the  literature,  with 
numerous  journals  and  books  dedicated  to  the  subject.  Many  of  the 
contnbutions  discuss  the  technical  nature  of  CSCW  systems  as  opposed  to 
descriptions  of  applied,  integrated  systems  -  of  which  the  latter  is  more  relevant 
to  this  research.  Even  in  cases  where  the  focus  of  the  work  was  targeted  toward 
applied  systems,  many  contributions  have  been  rendered  technologically 
obsolete  due  to  the  advent  of  Web-based  architectures.  A  relevant  example 
describing  applied  CSCW  systems  was  Munkvold  [42],  who  provided  case 
studies  on  the  use  of  collaborative  technologies  within  large  companies  like 
Boeing,  Grudin  [32],  and  Andriessen  [44],  who  described  the  types  of  variables 
that  can  affect  CSCW  systems. 

Romano,  Nunamaker  et.  al.  [45]  described  the  use  of  an  integrated 
information  retrieval  system  in  conjunction  with  Group  Support  Systems  (GSS). 
Romano’s  premise  is  based  on  users  ultimately  end  up  searching  for  information 
to  support  decision  activities,  and  a  linked  information  retrieval  system  will 
benefit  the  overall  decision-making  process.  In  almost  a  ’premonition’  to  this 
research,  Romano  opens  his  work  with  the  following  statement  -  “it  is  surprising 
to  the  authors  that  very  little  attention  has  been  given  to  the  common  ground 
shared  by  these  two  important  research  domains...”  [45].  Although  the  need  for 
information  filtering  was  mentioned  as  a  way  to  eliminate  redundant  data, 
Romano  does  not  offer  details  on  how  such  a  system  could  be  implemented 
Further,  the  authors  did  not  consider  how  large  information  sets  (potentially 
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returned  from  an  integrated  search)  can  possibly  blur  relevance  between 
relevant  and  useless  information  items 

For  a  solid  theoretical  overview,  Borghoff  and  Schlichter  [46]  offer  a  wide 
perspective  on  the  use  of  CSCW  with  an  important  discussion  on  workflow 
processing  Karsten  et.  al.  [47]  describes  the  impact  of  collaborative 
technologies  by  categorizing  the  usage  and  impact  of  the  tools  on  various 
organizations  with  an  innovative  “before  and  after'1  approach  In  terms  of  using 
CSCW  tools  as  a  central  component  to  product  development,  Mills  [33]  offers  a 
comprehensive  look  at  CSCW  and  Web-based  tools  that  are  linked  to  product 
development,  and  Monplaisir  and  Singh  [48]  tie  together  several  important  topics 
related  to  product  development  problems,  including  Monplaisir’s  review  of  CSCW 
fundamentals  and  Riordan's  discussion  of  decision-making  and  Groupware 
(where  the  elements  of  CSCW-based  decision-making  are  presented). 
Bochenek  et  al.  [49]  [132]  describes  the  use  of  collaborative  environments 
combined  with  virtual  reality  tools  to  support  design  reviews,  CSCW  and  virtual 
product  design  has  also  been  described  by  Steward  et.  al.  [50]  and  Kubo  et.  al. 
[51].  Other  good  references  where  CSCW  tools  have  been  used  support  group 
work  efforts  include  Patel  et.  al  [52]  and  Newman  et.  al.  [53]. 

Benyon-Davies  et.  al.  [54]  describes  the  use  of  conceptual  modeling 
related  to  linking  database  schemas  into  a  collective,  “collaborative11  system. 
The  process  by  which  the  schemas  are  linked  through  attribute  relationships  at 
the  sub-system  and  system  level  influences  data  management  for  this  research 
Benyon-Davies  also  proposes  CSCW  architectures  as  an  ideal  framework  on 
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which  to  develop  “collaborative"  database  schemas.  Dewan  [55]  proposes  the 
use  of  functional  decomposition  of  collaborative  systems  into  smaller 
subsystems,  whereby  various  models  and  requirements  can  be  developed.  The 
premise  of  the  modeling  activity  is  to  develop  an  architecture  that  offers 
complete  collaborative  capabilities 
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CSCW  WORKFLOW  MANAGEMENT  SYSTEMS 

Task  coordination  is  a  central  component  in  CSCW  applications. 
Workflow  systems  are  technologies  supporting  the  automation  of  work  activities 
by  routing  information  among  different  participants  according  to  a  predefined 
sequence  [42].  In  most  cases,  workflow  processes  are  implemented  after  a 
rigorous  information-gathering  activity  including  identification  of  requirements, 
development  of  functional  and  data  flows,  and  process  mapping.  More 
specifically,  workflows  represent  the  operational  aspect  of  a  work  procedure  - 
how  tasks  are  structured,  performed  (and  in  which  order),  level  of  syncronization, 
information  flows  to  support  the  tasks,  and  how  the  overall  process  is  being 
tracked  usually  through  the  measure  of  processing  rates  (as  a  dimension  of  time) 
and  overall  throughput  [67]  Workflow  processes  typically  embody  a 
formalization  of  work  activities  that  represent  organizational  “best  practices"  in 
order  to  drive  improvement  through  repetition 

In  general,  workflow  management  systems  have  been  well-documented  in 
the  literature,  including  several  complete  texts  dedicated  to  the  subject  by 
Khoshafian  et.  al  [56]  and  Jablonski  et.  al.  [57],  Borghoff  et.  al.  [46]  provides  an 
excellent  theoretical  overview  of  workflow  processing  and  definition.  Numerous 
accounts  of  successful  application  of  workflow  systems  can  be  found  in  the 
literature,  including  Ben-Shaul  et  al  [58],  Trung  et  al.  [59],  Muth  et.  al  [60],  and 
Adkinson  et.  al  [61],  where  described  improvements  include  improved  status 
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tracking,  consistency  and  conformity  to  work  standards,  improved  productivity, 
and  improved  management  support  through  balanced  task  allocation. 

Morschheuser  et.  al.  [62]  provides  a  good  non-Web  based  algorithm  for 
locating  pertinent  documents  using  workflow  processing  Of  particular  interest  is 
the  opening  statement  -  "...information  which  is  embedded  in  paper  documents 
is  partially  or  entirely  lost  after  their  active  processing  has  terminated...”  -  which 
is  an  influence  on  this  research  (making  use  of  decision  information)  Cho  et  al. 
[63]  uses  a  model-based  approach  for  linking  metadata  from  CAD  systems  and 
plant  floor  systems  within  a  workflow  application  to  support  traditional  back-end 
processing  activities.  McClatchey  et  al  [63]  applies  workflow  systems  to 
product  development  using  several  examples,  and  Kang  et  al  [66]  describes  the 
use  of  a  secure  workflow  system  as  the  core  for  distributed  task  management  in 
a  DoD  environment  for  passing  sensitive  information  between  domains. 
Munkvold  [42]  lists  workflow  integration  with  legacy  applications  as  an  important 
implementation  factor  for  "coordination"  of  technologies. 

While  an  important  element  in  business  process  optimization,  some 
documented  examples  describe  less-than-optimal  workflow  system 
implementations.  Weske  et.  al  [64]  and  Bowers  et.  al.  [65]  detail  problems 
including  a  lack  of  detailed  planning  and  prototyping  in  the  workflow  development 
process,  inadequate  translation  of  the  business  process  into  workflow  activities, 
and  system  performance  issues. 

An  important  aspect  related  to  the  research  is  the  use  of  workflow 
applications  to  link  CSCW  and  organizational  data  sources.  To  improve  internal 
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work  processes  or  leverage  information  for  competitive  advantages  [68],  many 
organizations  are  attempting  link  business  systems  to  provide  a  fluid  movement 
of  various  types  of  data  throughout  the  enterprise.  Liang  et.  al  [69],  Chang  et. 
al.  [70]  and  Simone  et.  al.  [71]  propose  a  CSCW  architecture  that  includes 
considerations  for  using  data  sources  from  other  business  applications. 
Reinhard  et.  al.  [72]  describes  the  taxonomy  of  a  CSCW  architecture  with 
“collaboration  transparent”  applications 

From  a  perspective  of  technology  choices  for  workflow-based 
applications,  Schmidt  [73]  offers  an  overview  of  evolving  workflow  technologies, 
while  Wade  et  al.  [74]  and  Delic  et.  al  [75]  each  propose  using  a  CORBA-based 
architecture.  Du  et.  al.  [76]  uses  a  distributed  model  for  allocating  resources 
within  the  workflow  process  and  offers  a  useful  layered  model  (similar  to  the  OSI 
model)  for  accessing  resources.  Ganesarajah  et  al.  [77]  use  a  “SOAP-over- 
HTTP”  architecture  for  integrating  workflow  systems,  thus  providing  a  way  to 
incorporate  Internet-based  sources 

From  a  design  and  construction  perspective,  Hawryszkiewycz  [78] 
describes  a  design  methodology  centering  on  CSCW  and  Heinl  et.  al.  provides 
guidelines  for  flexible  design  practices  in  workflow  systems  [93]  Contributions 
supporting  XML  modeling  within  CSCW-based  applications  include  Marsic  et.  al. 
[79]  and  Ma  [80],  Literature  aimed  at  XML-based  transactions  within  workflow 
processes  includes  Yang  et.  al.  [81],  Lear  et.  al.  [82],  and  Kanaya  et.  al.  [83]. 
Aversano  et  al.  [84]  proposes  using  XML  as  a  medium  for  distributed  document 
management  and  workflow  processing  and  recommends  the  UML  for  core  data 
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modeling  Later,  Aversano  et.  al.  [85]  uses  UML-based  modeling  -  in  particular 
activity  diagrams  and  use  cases  -  to  develop  workflows  for  a  variety  of  systems. 
Finally,  Agostini  et.  al.  [86]  offers  a  short  specification  for  complex  workflow 
modeling  through  decomposition  and  development  of  “simple"  workflow  models. 
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CONTENT  RETRIEVAL  TECHNOLOGIES 

Among  the  most  important  tools  developed  for  Web-based  processing  are 
those  designed  to  conduct  searches  based  on  one  or  more  keywords.  Although 
the  search  and  return  sequence  is  a  near-seamless  transaction  to  the  end  user, 
these  actions  are  typically  the  result  of  complex  data  gathering  and  sorting 
activities.  Given  the  importance  of  Web  searches  to  Internet  use,  search  tools 
have  essentially  become  the  “card  catalog”  system  of  the  Internet  [87], 

Search  engines  use  a  variety  of  mechanisms  (including  human 
interpretation)  [88]  to  continually  identify  and  categorize  new  information  from  the 
Web.  After  classification,  search  engines  employ  a  series  of  conditional 
probability  techniques  to  sort  and  rank  data  Many  of  the  leading  search 
technologies  use  Bayesian  principles  to  synthesize  representations  of  conditional 
probabilities  [89]  or  filter  information  based  on  key  attributes  [90]  Gupta  et  al. 
[88]  proposes  a  search  engine  architecture  to  allow  “fresher"  information  and 
data  to  be  brought  forward  more  easily  within  Web  searches.  Henzinger  et.  al 
[91]  describes  a  search  engine  ranking  algorithm  based  on  the  comparison  of  a 
number  of  similar  parameters,  and  Hou  et.  al.  [92]  expands  on  the  comparison 
techniques  by  adding  additional  components  into  the  search  algorithm.  Beyond 
text-based  searches,  Funkhouser  et  al.  [94]  developed  query  heuristics  based 
on  orientations  and  design  similarities  to  search  within  3D  models  and  drawings 
Linden  et  al.  [90],  uses  content  filtering  agents  to  extract  a  very  small  subset  of 
personalized  recommendations  from  an  extremely  broad  data  pool  Linden's 
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model  represents  a  real-world  application  of  item  filtering  and  selection 
(Amazon  com). 
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DECISION  UNCERTAINTY 

Decision  analysis  is  a  discipline  comprised  of  theories,  methodologies, 
and  practices  necessary  to  address  making  important  choices  in  a  formalized 
manner  -  particularly  in  situations  having  levels  of  uncertainty  [95].  The  rich 
history  of  contributions  in  the  area  of  decision  analysis  includes  Clemen  [96], 
Raffia  [97],  Howard  et  al.  [98],  and  Skinner  [99],  among  others  Branches  of 
decision  analysis  are  rooted  in  Operations  Research  practices  [100],  DSM,  and 
software  system  design  [101]  Pablo  et,  al.  [114]  ties  concepts  of  decision 
making  as  being  central  to  understanding  risk,  and  Richardson  et  al  [115] 
frames  decision  making  within  a  decentralized  environment,  concluding 
organizational  characteristics  play  a  larger  role  in  decision  making  performance 
than  other  factors. 

Two  areas  of  interest  within  decision  analysis  play  an  integral  role  in  the 
formulation  of  the  framework  The  first  area  is  role  of  bias  as  it  affects 
uncertainty  in  decision  making.  According  to  the  Prospect  Theory  developed  by 
Amos  Tversky  and  Daniel  Kahneman,  decision  makers  evaluate  gains  and 
losses  to  assess  decision  alternatives  based  on  personal  bias  [102].  Evaluations 
of  alternatives  are  based  on  a  reference  point  where  decisions  gravitate  toward 
According  to  Tversky  and  Kahneman,  several  important  heuristics  and  biases 
come  into  play  during  decision  making: 

•  Representativeness  -  Judgments  of  probability  are  based  on  what 
is  perceived  as  similar  to  a  belief  or  known  quantity. 
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•  Availability  -  Concentrating  primarily  on  evidence  that  is  easily 
obtained  or  immediately  available 

•  Anchoring  -  Concentrating  on  evidence  or  facts  that  are  presented 
first  in  the  overall  set. 

Mellers  et.  al  [116]  follows  Tversky’s  work  with  studies  on  how  emotion, 
beliefs,  and  “rule  following"  also  contribute  to  the  psychological  makeup  of  the 
decision  maker. 

The  second  area  of  interest  is  the  assessment  of  risk  and  the  role  risk 
plays  in  decision-making.  Risk,  in  its  basic  definition,  is  the  potential  harm  that 
may  arise  from  some  present  process  or  from  some  future  event  [103]  The 
realm  of  risk-related  topics  and  research  is  extensive  as  related  to  product 
development.  Smith  et  al  provides  a  detailed,  multi-step  approach  to  monitoring 
and  managing  risk  in  new  product  development  [104],  Davis  leverages  the  use 
of  “net  present  value,  risk  adjusted”  (NPVR)  to  evaluate  relative  risk  in  product 
development  projects  [105]  Thornton  focuses  on  variation  quality  as  related  to 
Six  Sigma  practices  [106].  Kraniak  et.  al  shows  how  historical  data  for  product 
development  as  related  to  manufacturing  planning  can  be  effective  for  use  in 
Failure  Mode  and  Effects  Analysis  (FMEA)  data  [107]. 

A  common  method  of  risk  assessment  is  to  arrive  at  an  optimal  decision 
through  decision  trees.  Decision  trees  are  used  to  arrange  outcomes  of  decision 
in  a  series  of  nodes  with  associated  risk  probabilities  and  costs  called  branches 
[100]  [108]  Decision  trees  are  typically  leveraged  in  two  ways  -  traditional 
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optimization  problems  involving  the  application  of  possible  outcomes  combined 
with  a  calculated  probability  [109]  or  a  classification  structure  to  based  on 
training  data  within  the  realm  of  artificial  intelligence-based  learning  [110  ]. 
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LITERATURE  GAPS 

As  stated  in  the  introduction  to  this  chapter,  foundations  of  the  core 
research  can  be  considered  “ground  well  covered".  However,  important  gaps  in 
the  literature  have  been  identified. 

•  The  need  for  a  comprehensive,  focused  approach  for  optimizing 
CSCW  environments  for  product  development  activities  during 
planning,  implementation,  and  production  While  several  works 
mention  using  CSCW  within  the  mechanics  of  product 
development  decision  making  at  a  high  level,  the  framework  offers 
practical  optimization  steps  for  both  implementers  and  users  In 
contrast,  none  of  the  reviewed  works  provide  more  than 
rudimentary  discussions  with  functional  or  technical  detail 

•  The  research  provides  a  path  for  the  use  of  past  decisions  and 
relevant  historical  data  points  for  decision  makers.  While  Romano 
and  Nunamaker  [45]  make  reference  to  decision  data  as  one  point 
of  information,  no  literature  goes  into  sufficient  detail  on  harnessing 
concept-based  decisions  for  future  usage 
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CHAPTER  3  -  METHODOLOGY 

As  presented  in  Chapter  1 ,  the  premise  of  the  framework  is  based  on  the 
research  question  -  What  can  be  done  to  optimizing  the  current  spectnjm  of 
development-focused  computer  tools  to  allow  improvement  by  reducing  levels  of 
uncertainty  in  concept  development  based  decision-making?  In  Chapter  2,  core 
fundamentals  on  which  the  framework  has  been  based  were  presented, 
including  an  explanation  of  the  concept  development  (and  product  development) 
phases  as  well  as  applicable  computer  technologies,  theories,  and  processes 

The  purpose  of  this  chapter  is  to  provide  in-depth  information  related  to 
the  framework  by  defining  its  major  elements,  implementation  strategies  and 
associated  methods  To  understand  how  the  research  can  contribute  to 
improving  concept  development  processes,  an  investigation  was  undertaken 
which  provided  indicators  that  allowed  the  core  framework  elements  to  be 
identified  The  bulk  of  this  chapter  is  devoted  to  an  in-depth  explanation  of  the 


research  framework  elements. 
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SURVEY  OF  PRODUCT  DEVELOPMENT  ORGANIZATIONS 

A  starting  point  for  understanding  how  the  framework  can  impact  concept 
development  was  to  gather  a  small  sampling  of  feedback  on  how  organizations 
approach  product  development.  The  data  gathering  approach  consisted  of 
identifying  individuals  from  a  variety  of  product  development  communities  and 
extracting  a  baseline  of  experiences  through  a  review  of  concept  development 
activities. 

Members  of  the  product  development  communities  contributing  to  the 
data  gathering  activities  ranged  from  small  companies  to  multinational 
corporations  in  the  automotive,  software,  and  defense  areas.  Individuals 
involved  with  product  development  activities  were  directly  queried  regarding  their 
processes,  information  systems,  and  issues  with  moving  concepts  forward.  The 
feedback  was  collected  by  utilizing  live  interviews  and  a  written  questionnaire 
(which  can  be  found  in  Appendix  A). 

Product  Development  Processes  and  Tools 

•  Most  respondents  utilize  some  level  of  product  development 
processes  involving  computer-based  information  systems. 
Typically,  the  larger  the  organization  (and  “deeper  the  pockets”  for 
investing  in  tools),  the  higher  the  degree  of  automation  tools  for 
concept  development,  data  management,  and  collaboration  (such 
as  workflow  systems).  Further,  many  of  the  organizations  rely  on 
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internally-developed  processes  synthesized  over  time  from 
successful  practices. 

•  Typically,  computer-based  tools  are  either  custom  applications 
developed  internally  or  commercial  applications  tailored  to  the 
needs  of  the  organization's  product  development  activities  While 
custom  applications  may  provide  a  better  fit  into  an  organization’s 
existing  product  development  activities,  substantial  resources  are 
needed  to  maintain  the  systems.  Conversely,  while  commercial 
applications  may  not  require  the  same  level  of  dedicated  resources 
for  maintenance,  commercial  applications  offer  an  approach  to 
working  with  data  that  can  be  substantially  different  to  what  an 
organization  practices.  In  many  cases,  commercial  applications 
are  customized  to  work  within  the  parameters  of  existing  product 
development  practices.  Unfortunately,  highly  customized 
commercial  systems  typically  have  many  of  the  same  maintenance 
issues  as  “in-house”  developed  applications. 

•  At  the  "low"  end,  smaller  organizations  do  not  typically  use 
sophisticated  data  management  and  automation  tools  but  rather 
rely  on  rudimentary  computer  tools  (such  as  a  shared  disk  drives) 
for  managing  information  In  some  cases,  teams  rely  on  managing 
portions  of  data  and  processes  on  external  or  customer  systems. 
Interaction  and  data  exchange  between  multiple  disciplines  on 
concept  decisions  (e  g.  engineering,  manufacturing,  design, 
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financial)  continues  to  be  influenced  in  part  by  existing  personal 
relationships  between  participants. 

•  In  some  cases,  computer  systems  deployed  to  support  and 
streamline  product  development  and  decision-making  activities  fall 
short  of  their  intended  goals  In  hindsight,  some  of  the  shortfalls 
can  be  traced  to  the  implementation  issues  -  lack  of  information 
used  for  planning,  deployment,  adoption,  and  sustainment 

Data  Usage,  Lessons  Learned,  and  Decision  Making 

•  The  ability  to  locate  information  in  organizational  computer  systems 
can  be  challenging.  In  some  cases,  decision  makers  feel  they  do 
not  have  access  crucial  information  they  should  have  -  and  know 
exists  -  because  of  the  existing  computer  tools  and  supporting 
processes.  In  other  cases,  decision  makers  use  free  form 
searches  in  an  attempt  to  discovered  information  that  they  think 
may  exist  which  could  support  their  needs  -  “if  we  only  knew  what 
we  know”  [13]. 

•  The  practice  of  capturing  lessons  learned  -  knowledge  intended  to 
help  educate  and  aid  in  making  future  decisions  -  is  usually 
formalized  through  “project  notebooks”  or  post-mortem  activities 
such  as  an  After  Action  Reviews  (AAR).  While  lessons  learned 
information  through  these  methods  can  be  captured  in  computer 
systems,  it  is  typically  not  stored  or  linked  in  a  manner  allowing  it  to 
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be  readily  applied  to  future  decision  making  activities  Most 
respondents  would  welcome  better  ways  for  capturing  and  sharing 
both  formal  and  tacit  knowledge  relative  to  decision  making 

•  The  inability  to  locate  and  leverage  information  from  organizational 
computer  systems  for  decision  making  activities  is  a  byproduct  of 
how  the  system  was  implemented  and  how  it  is  maintained  The 
sheer  physical  bulk  of  information  that  large  enterprise  information 
systems  manage  can  extend  well  into  terabytes.  Even  those 
respondents  without  the  resources  to  implement  formal  CSCW 
systems  (and  thus  use  rudimentary  tools  such  “shared  disk  drives" 
for  cooperative  data  management)  mentioned  issues  with  retrieval 
and  reuse  Without  an  adequate  data  management  strategy, 
locating  information  can  become  an  overwhelming  chore.  Further, 
the  associated  time  required  to  do  an  extensive  data  search  by  a 
decision  maker  may  quickly  exceed  the  overall  need  to  use  the 
information  in  a  decision  making  activity. 

•  Decisions  are  typically  based  on  an  analysis  of  information 
available  on  the  problem  as  well  as  personal  perceptions, 
preferences,  and  knowledge  (best  supported  by  Tversky  et.  al 
[102]).  Unfortunately,  the  knowledge  and  perspective  of  one 
decision  maker  does  not  readily  transfer  to  another.  Workers 
change  jobs  frequently,  and  typically  knowledge  is  not  retained  to  a 
level  allowing  for  replacements  to  quickly  understand  the  decision 
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environment.  While  some  generic  lessons  learned  may  be 
recorded,  rarely  does  transferable  “insight"  to  why  a  decision  was 
made  -  which  could  help  a  future  decision  maker  faced  with  similar 
circumstances  -  get  captured. 

•  Data  derived  from  past  decisions  useful  for  future  decision  making 
is  related  to  cost,  deliverables,  or  timing  All  other  decision 
circumstances,  in  general,  have  little  value  outside  of  the  particular, 
point  decision. 

•  The  “need”  -  as  reflected  through  the  original  concept  and 
subsequent  requirements  -  should  ultimately  the  standard  by  which 
the  decision  should  be  measured  If  a  decision  has  measurable 
impact  on  the  original  “need”  as  related  to  cost,  deliverables,  or 
timing,  then  it  becomes  a  candidate  for  information. 

Analysis  and  Framework  Summary 

Taking  into  account  the  literature  review  and  survey  it  is  clear 
opportunities  exist  to  improve  systems  used  to  facilitate  concept  development 
processes.  Clarifying  the  targets  of  the  research,  the  concentration  will  be  on 
methods  that  can  provide  a  measure  of  impact  in  the  following  three  areas; 

•  Improving  lessons  learned  and  organizational  knowledge. 

•  Locating  and  managing  conceptual  product  development 


information 
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•  Improving  decision-making  in  concept  development  activities. 

The  remainder  of  the  research  describes  a  framework  by  which  actions 
can  be  taken  to  make  improvements  in  the  aforementioned  areas,  The 
framework  is  composed  of  four  core  elements  (briefly  summarized  below)  with  a 
goal  presenting  a  rich,  succinct  data  set  to  decision  makers  to  allow  for  additional 
information  to  be  utilized  in  the  decision  making  process. 

1 .  Implement  a  hierarchically-based  CSCW  architecture  for 
managing  all  data  and  aspects  of  the  concept  development 
process 

a  Follow  a  structured  implementation  process 

b.  The  CSCW  architecture  must  have  the  ability  to  foster  process 
management 

c  Constructed  with  philosophy  of  most  data  captured  has  little 
future  use  with  decision  makers 

d  Utilize  a  series  of  “measurement”  attributes  to  assess  the  value 
of  data  for  future  decision  making  tasks 

2.  Leverage  the  use  of  past  decision  data  within  work  processes 

a  Creation  of  a  decision-focused  mechanism  allowing  appropriate 
data  to  be  captured  at  a  level  that  supersedes  traditional  data 
management  objects 
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b  Creation  of  the  "Need-Decision-Result"  relationship  linking 
needs  to  actions  and  outcomes 

c.  Utilize  a  criteria  based  on  three  core  factors  -  cost,  timing,  and 
deliverables  -  combined  with  traditional  metadata  to  identify 
relevant  decisions. 

3.  Organization  of  data  elements  baselined  around  a  robust  product 
development  process . 

4.  Integrate  risk  assessment  providing  awareness  to  specific  data 
points  that  could  have  relevance  to  a  decision. 

The  four  steps  cover  both  implementation  and  usage  of  an  environment 
suited  for  a  concept  development  decision-making  environment.  While  each 
element  can  be  implemented  independently  and  outside  of  the  context  of  the 
framework,  it  should  be  noted  the  intent  is  for  the  elements  to  be  used  together 
to  create  a  synergy  for  optimization  beyond  what  is  attainable  if  employed 
separately. 
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ELEMENT  1  -  IMPLEMENT  A  HIERARCHICALLY-BASED  CSCW 
ARCHITECTURE  FOR  MANAGING  ALL  ASPECTS  OF  THE  CONCEPT 
DEVELOPMENT  PROCESS 

The  cornerstone  of  the  framework  is  the  creation  of  an  environment  from 
which  data  can  be  captured,  managed,  and  leveraged  for  an  organization.  The 
purpose  of  this  section  is  to  clarify  the  components  and  structure  of  the  essential 
CSCW  elements  critical  as  a  foundation  for  other  portions  of  the 

Core  CSCW  Architecture  Elements 

The  essential  components  required  for  a  CSCW  system  to  support  a 
product  development  framework  are  summarized  below.  Because  many  of 
these  features  can  be  found  in  commercially-available  software  products, 
CSCW  system  implementers  should  strongly  consider  advantages  of  starting 
from  Commercial  ''Off-the-Shelf  Technology  (COTS)  over  creating  custom 
applications  from  scratch. 

Object-Oriented  Behaviors  Data  structures  supported  in  the  CSCW 
environment  should  be  based  on  an  object-oriented,  expandable  hierarchy  with 
persisted  objects  representing  data  and  actions.  Objects  should  be  able  to  be 
linked  through  a  variety  of  explicit  relationships  The  ability  to  ‘manage’ 
perstistable  data  objects  should  be  based  on  pre-defined  behavioral 
characteristics  as  well  as  a  user-  specified  data  hierarchy  (based  on  locations, 
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user  roles,  and  other  explicitly  defined  conditions).  Each  data  entity  managed 
within  the  CSCW  environment  typically  contains  two  core  features  -  content 
such  as  an  electronic  file  (e.g.,  Microsoft  Word  documents,  CAD  file)  and  context 
in  the  form  of  field-based  metadata  that  describes  the  associated  content  and 
other  information  used  to  describe  the  entity.  More  importantly,  data  objects 
defined  in  the  system  should  cover  all  types  of  information  used  or  stored 
throughout  the  life  cycle  of  the  product  -  from  concept  “bubble-up”  to  planned- 
manufacturing  obsolescence. 

Relational  Database  Repository.  CSCW  data  elements  should  be 
managed  within  a  relational  database  repository.  Most  commercial  CSCW 
systems  rely  on  a  relational  database  such  as  Oracle,  Microsoft  SQL  Server,  or 
MySQL  to  manage  the  physical  warehousing  of  data  elements. 

Context  Search  and  Retrieval.  The  system  must  have  the  ability  to 
support  queries  for  searching  database  tables  and  related  repositories 

Process  Standardization  Tools 

The  system  must  provide  mechanisms  to  support  formalized  work 
processes  involving  a  series  of  defined  events  In  many  cases,  CSCW 
environments  and  other  systems  use  workflow-based  objects  and  applications  to 
formalize  activities  by  routing  tasks  to  pre-defined  users  (or  roles)  for  completion 
of  a  specific  action  In  some  tasks,  workflow  objects  capture  decision  data  to 
record  an  action  on  a  particular  item  Most  workflow  processes  are  designed 
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primarily  to  standardize  and  streamline  work  activities  by  ensuring  the 
appropriate  tasks,  roles,  and  users  are  identified 

Typically  accompanying  structured  workflows  are  life  cycle  phases  which 
represent  the  maturity  of  a  data  element  in  the  development  cycle  Together, 
workflows  (as  the  specific  tasks  to  be  completed)  and  lifecycles  (representing  the 
maturity  of  the  data  item)  represent  an  approach  known  as  the  “phase-gate”  (or 
“stage-gate”)  process  [113].  Life  cycle  phase  data  can  be  a  useful  element  for 
filtering  past  decision  data. 

Controlled  Data  Hierarchy  -  Detailed  Planning  and  “Matrixed”  Information 
Approach 

System  implementers  must  make  understanding  how  to  structure  the 
product  information  ultimately  managed  within  the  system  a  priority. 
Implementers  must  understand  and  gauge  four  key  characteristics  of  information 
before  it  becomes  managed  within  the  CSCW  environment 

•  How  data  is  created  (by  users  or  automated  processes) 

•  Where  data  will  be  structurally  stored  within  the  environment 

•  What  information  regarding  the  managed  data  is  important  to  end 
users 


How  data  elements  will  be  related  to  one  another. 
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In  many  cases,  CSCW  system  deployments  focus  more  on  the  "act"  of 
implementing  the  tools  rather  than  understanding  the  mechanics  of  the  data  to 
be  managed  in  the  system  In  some  situations,  this  lack  of  consideration  for  long¬ 
term  data  usage  results  in  a  “scattershot”  approach  to  data  management  - 
multiple  data  hierarchies  with  a  localized  data  management  approach,  thus 
creating  “information  silos". 

In  any  data  managed  environment,  a  hierarchy  of  information  will  evolve 
in  one  manner  or  the  other  as  a  result  of  planning  or  forecasting  -  or  the  lack  of 
it.  Without  a  defined  data  hierarchy  implemented  at  the  time  of  system 
deployment,  additional  context  and  knowledge  obtained  from  implementing  the 
framework  elements  will  likely  be  less  effective  since  an  underlying  principle  in 
the  application  of  the  framework  is  the  ability  to  closely  link  a  variety  of 
information  sources  related  to  before,  during,  and  after  a  decision  has  been 
made. 

As  mentioned,  “scattershot”  data  hierarchies  are  sometimes  a  byproduct 
of  how  system  implementation  projects  are  conducted.  In  some  cases, 
resources  from  outside  the  end  user  organization  (IT  consultants)  are  brought  in 
to  deploy  the  CSCW  system  with  project  schedules  emphasizing  deployment 
milestones  and  financial  targets  General  requirements  and  organizational  data 
flows  are  gathered  through  interviews  and  studies,  but  depending  on  the  focus 
provided  by  the  project  team  these  efforts  may  not  result  in  an  intrinsic 
understanding  of  how  data  is  captured  and  leveraged  by  end  users.  Conversely, 
end  users  and  customers,  not  versed  in  deploying  CSCW  technologies,  usually 
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do  not  have  enough  understanding  of  the  “to  be”  environment  to  be  able  to  fully 
consider  all  aspects  of  data  use.  The  result  is  a  good  technological  solution 
without  a  solid  data  hierarchy  and  plan  where  the  end  user  is  left  to  decide  the 
'fate’  of  the  data  within  the  system 

In  unregulated  situations,  users  have  the  ability  to  store  information  in 
virtually  any  accessible  location.  If  data  management  standards  are  not 
established  or  are  misunderstood,  a  data  hierarchy  based  on  local  (or  individual) 
standards  will  grow  with  few  opportunities  to  link  information  data  elements 
beyond  its  singular  context.  More  importantly,  opportunities  to  “discover” 
information  are  reduced  due  to  inconsistent  data  management  approaches 
Figure  3.1  provides  a  representation  of  a  localized,  or  “scattershot”  data 
hierarchy. 
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Figure  3.1  Localized  (“Scattershot”)  Data  Hierarchy 
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When  considering  how  to  forecast  a  hierarchical-based  data  environment 
optimized  for  an  organization,  one  recommendation  is  to  identify  the  information 
flow  that  works  best  from  both  an  end  user  perspective  and  a  data  relationship 
perspective  An  approach  for  consideration  is  to  construct  a  "matrixed"  view  of 
data  for  the  CSCW  environment.  Loshin  [111]  mentions  a  matrixed  perspective 
for  data  validation  during  system  development  In  a  matrixed  view,  major  data 
categories  are  identified  based  on  forecasting  necessary  data  types.  Data 
categories  referring  to  a  specific  entity  (e.g.  leveraging  basic  “noun”  principles  of 
“person”,  "place”,  or  “thing")  could  be  considered  one  type  of  category 
Examples  would  include  references  to  concepts  or  physical  end  products. 
Conversely,  data  categories  that  represent  “descriptive"  applications  of  data  are 
another  category.  Specific  data  types  such  as  program  plans,  requirements,  and 
studies  represent  subjective  characteristics.  In  the  matrixed  hierarchy,  the 
intersection  of  specific  entity  and  descriptive  data  elements  (e.g.  "the  project  plan 
for  a  concept  program”)  provides  a  location  where  the  data  element  should 
reside  in  the  hierarchy. 

Figure  3.2  shows  a  representative  data  matrix  of  information  based  on 
entity  and  descriptive  elements.  Entities  are  shown  along  the  horizontal  axis 
(programs  and  products)  and  descriptive  identifiers  are  arranged  along  the 
vertical  axis  (demonstrations,  meetings,  and  vendors)  Although  not  shown, 
within  major  categories  a  number  of  sub-categories  may  exist 
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Figure  3.2  Matrixed  Data  Hierarchy 

Because  only  a  subset  of  data  has  value  to  future  decision  makers,  the 
matrixed  hierarchy  promotes  an  efficient  data  management  arrangement  by 
keeping  the  most  important  data  elements  at  the  highest  level.  The  matrixed 
hierarchy  also  provides  a  starting  point  for  locating  information,  thus  reducing  the 
chance  of  creating  independent  information  “silos”. 

One  caveat  is  since  most  computerized  environments  are  most  efficient  in 
managing  data  in  a  singular  hierarchy  (or  "top-down”  one-dimensional  approach), 
for  implementation  purposes  it  may  be  necessary  to  transpose  the  matrix  where 
one  type  of  category  (entities)  are  placed  in  a  superior  hierarchical  position  with 
the  support  of  the  other  category.  An  example  of  a  transposed  data  matrix  is 
provided  in  Figure  3  3. 
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Figure  3.3  Transposed  Data  Matrix  Hierarchy 


Dynamic  Data  Management 

Although  large  amounts  of  data  can  be  stored  indefinitely  in  computer 
managed  environments,  only  as  subset  of  the  information  has  value  beyond  its 
originally  intended  use.  Problems  resulting  from  massive  data  build-up  are 
mentioned  in  the  survey  -  in  particular,  difficulty  searching  and  locating 
information. 

CSCW  data  environments  working  within  the  research  framework  should 
be  construct  and  operated  with  a  dynamic  philosophy  that  most  of  the  data 
captured  has  little  future  use  with  decision  makers.  For  a  healthy  environment 
supporting  decision-making,  system  designers  must  capitalize  on  a  perishable 
quality  of  data  recognizing  a  finite  lifespan  of  usefulness.  Extending  a  concept 
from  Tversky  [102],  decision  makers  may  be  biased  by  the  first  sources  of 
information  in  hand  Therefore,  an  operating  principle  within  the  framework  is 
data  not  having  usefulness  should  be  pre-filtered  out  of  any  potential  list  of 
information  a  decision  maker  accesses  in  order  to  gather  inputs 

Indicators  in  the  form  of  attributes  are  needed  to  identify  concept  data  (i.e. 
deliverables,  not  specifically  decision  data  itself)  having  relevance  for  future  use. 
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There  are  obvious  'natural'  indicators  captured  as  part  of  the  metadata  itself  - 
primarily  the  age  of  the  data  item,  life  cycle  state,  or  specific  relationship  to  an 
important  concept  For  data  not  as  obviously  perishable,  straightforward  criteria 
should  be  deployed  as  part  of  the  managed  attribute  set  to  allow  data  creators 
an  opportunity  to  provide  a  measure  of  assessment.  To  facilitate  a  simple 
recommendation  process,  assessment-based  attribute  data  should  be  Boolean 
information  ala  check  box,  radio  button,  or  true/false.  How  data  may  be  relevant 
to  future  decision  makers  is  not  important  since  filtering  information  for  later  use 
will  be  a  feature  of  other  components  in  the  framework  as  well  as  be  a  weighting 
factor  for  search  engines.  However,  having  this  "pre-determination"  up  front 
helps  separate  potentially  relevant  data  from  other  information  having  no  further 
use 

In  general  cases,  the  following  information  elements  may  be  used  as  part 
of  the  decision  assessment  criteria  -  decision,  issue,  end  state ,  timeframe, 
milestone,  resource,  or  requirement.  Conversely,  data  items  not  falling  within  the 
pre-defined  criteria  well  eventually  become  data  SLOP  (Strategically  Limited, 
Obsolete,  Perishable).  SLOP  items  should  be  automatically  archived  or  deleted 
after  a  pre-determined  time.  Where  possible,  data  SLOP  items  should  have 
minimal  weighting  in  search  engine  indexing  (or  a  "negative”  weighting  over 
time). 
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ELEMENT  2  -  LEVERAGE  THE  USE  OF  PAST  DECISION  DATA  WITHIN 

WORK  PROCESSES 

According  to  Ulrich  and  Eppinger,  it  is  in  the  concept  development  phase 
where  the  needs  of  the  target  market  are  identified,  alternative  product  concepts 
are  generated,  and  concepts  are  selected  for  further  development  and  testing 
[2].  To  translate  requirements  (in  terms  of  wants  and  needs)  into  workable 
concepts,  numerous  activities  and  decisions  must  be  completed  during  the 
process.  Ultimately,  decision  results  from  concepts  influence  activities  far 
beyond  the  concept  development  phase. 

Decision  makers  interpret  alternatives,  assess  information,  and  make 
comparisons  in  order  to  develop  a  conclusion.  As  discussed  in  Chapter  2  within 
the  context  of  Tversky’s  heuristics  and  biases  [102],  decision  makers  draw 
insight  from  data  in  hand  and  personal  experience.  The  value  decision  makers 
bring  to  this  process  is  their  ability  to  make  complex  rationalizations  from  a 
limited  information  set.  As  evident  from  the  literature  and  survey,  improvements 
are  welcome  for  capturing  organizational  memory  beyond  traditional  “lessons 
learned”. 

Gaining  context  how  decisions  have  been  made  or,  more  importantly, 
played  out  over  time  becomes  an  intriguing  component  for  leaders  While  the 
decision  itself  may  have  some  use  as  a  precedence  (most  prominently  in  design, 
where  concepts  of  design  intent  and  design  rationale  are  used  to  designers),  it  is 
how  previous  decisions  were  arrived  at  -  in  particular  what  were  the  key 
motivating  factors  -  and  the  “before"  and  “after'1  view  of  the  sequence  of  decision 
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events  which  may  be  of  more  interest.  Therefore,  harnessing  data  from  the 
decision  making  mechanics  becomes  an  asset  for  sharing  with  other  leaders  in 
the  organization.  It  is  within  this  context  a  core  element  of  the  framework  -  the 
mechanisms  to  capture  and  leverage  information  from  past  decisions  -  is 
presented. 

Within  the  framework,  three  important  structural  components  must  be 
added  to  take  advantage  of  decision  data 

1.  Development  of  a  decision-focused  object  allowing  related  decision 
data  to  be  captured  at  a  level  that  supersedes  traditional  CSCW 
objects. 

2.  Creation  of  the  “Needs-Decision-Result"  relationship  linking 
“before”  and  “after”  data  elements  to  the  decision. 

3.  Utilization  of  a  criteria  based  on  three  core  factors  -  cost,  timing, 
and  deliverables  -  combined  with  traditional  metadata  to  identify 
relevant  decisions. 

Creation  of  a  Decision-Focused  Object 

As  previously  mentioned,  a  data  model  used  by  many  CSCW  systems  is 
based  on  a  hierarchy  of  objects.  Objects  are  used  to  represent  tangible,  “real” 
data  elements  containing  metadata  and  physical  content  in  some  state  of 
development.  Typical  object  hierarchies  may  include  objects  representing  parts, 
products,  documents,  requirements,  drawings,  or  change-related  items.  All 


55 


objects  are  usually  descendents  from  a  simple  object  defining  a  basic  set  of 
properties  or  behaviors.  Another  class  of  objects  describes  actions  taken  on 
core  objects,  such  as  workflow  data. 

Within  the  use  of  “core”  and  “support”  objects  to  represent  decision 
information,  some  gaps  may  exist  in  the  hierarchy  to  enable  management  of 
detailed  decision  context  for  capture  or  reuse  [112],  In  these  cases,  the  only 
consistent  placeholder  for  decision  data  is  workflow  tasks  In  this  context, 
workflows  become  essentially  “one-dimensional”  tools  not  extendable  beyond 
basic  task  management  activities  A  task  is  provided  to  a  decision  maker 
through  the  CSCW-based  application  with  links  to  data  for  which  a  decision  must 
be  made.  Decision  outcome  are  registered  within  the  CSCW  system  for  the  data 
item  with  some  additional  generic  comments  from  the  decision.  Once  the 
decision  is  made,  results  and  comments  are  recorded  and  the  task  is  considered 
finished,  left  to  become  part  of  the  vast  archive  of  information.  Other  than 
reporting  purposes,  the  workflow  decision  activity  (and  data)  has  no  further 
value.  Decisions,  for  all  practical  purposes,  become  byproducts  of  a  series  of 
activities  undertaken  to  achieve  a  series  of  stated  purposes.  In  CSCW  systems 
used  for  product  development,  the  end  product  becomes  the  focus  of  attention 
(both  present  and  future),  not  key  decisions. 

In  the  framework  context,  decisions  should  be  elevated  to  a  level  in  the 
object  hierarchy  equivalent  or  superior  to  core  objects  and  data  The  objective  is 
to  place  the  decision  as  a  stand-alone  entity  with  linkages  to  data  or  processes 
that  have  influenced  (or  been  influenced  by)  the  decision  Therefore,  a  new 
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object  (henceforth  referred  to  as  the  decision  object)  should  be  developed  for 
use  by  the  CSCW  environment  to  focus  solely  on  the  capture  and  reuse  of 
decision  data  From  a  hierarchy  perspective,  the  decision  object  becomes  a  key 
collection  points  for  concept  information.  Much  of  the  metadata  information 
representing  the  decision  object  will  be  similar  to  standard  content  objects  (with 
fields  such  as  “Product",  "Program",  "Name",  "Date”).  Although  each  core  data 
object  offers  relationships  to  other  data  elements,  the  decision  object  provides  a 
comprehensive  view  of  related  information  For  this  reason,  the  decision  object 
must  have  the  ability  to  be  searchable  and  have  a  relatively  simple  access  point 
for  acquiring  information 

Another  important  consideration  relevant  to  the  functionality  of  the  object 
is  in  practice,  any  "major”  decision  concept  is  the  result  or  aggregate  of  a  number 
of  smaller  and  less  encompassing  decisions  Therefore,  from  a  design 
perspective,  no  structural  distinction  between  major  and  minor  decisions  will  be 
made,  but  the  ability  to  denote  a  “major”  decision  (e  g.  ’importance’)  will  be 
added  to  the  schema. 

In  previous  sections,  reference  has  been  made  to  capturing  and 
leveraging  past  decision  data  with  a  premise  of  the  act  of  the  decision  itself  may 
offer  very  little  value  to  decision  makers.  Rather,  it  is  circumstances  before  and 
after  coupled  with  the  decision  -  if  captured,  stored,  and  presented  in  a  useful 
manner  -  that  offers  a  potential  windfall  of  information.  The  decision  object  has 
been  offered  as  a  container  to  explicitly  map  information  related  to  the  decision. 
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The  Need-Decision-Result  Relationship 

A  decision  represents  a  point  in  time  separating  two  succinct  phases  - 
data  leading  up  to  a  decision  being  made  and  data  used  after  the  decision 
Assume  there  are  data  points  representing  the  primary  motivators  as  to  why  a 
decision  was  rendered  These  primary  items  describe  the  need  Events  and 
actions  captured  farther  out  over  time  after  a  decision  collectively  represent  the 
result.  Therefore,  the  three  elements  related  to  each  other  in  the  same  stream 
can  be  aggregated  as  the  Need-Decision-Result  relationship,  or  NDR  The  NDR 
relationship  represents  traceable  linkages  to  relate  the  three  data  types  in  a 
manner  describing  the  circumstances  of  the  decision  over  time. 

To  further  refine  the  three  elements  (need,  decision,  result),  the  following 
inferences  will  be  made  to  the  NDR 

•  The  need  is  represented  in  the  data  hierarchy  as  a  singular  item 
Each  'need'  can  be  represented  by  one  data  item  -  a  statement, 
recognized  deficiency,  question,  or  hypothesis  Simply  stated,  the 
need  is  the  starting  point  from  which  the  NDR  can  be  established. 

•  Decisions  made  to  take  an  action  on  a  need  may  be  represented 
by  1  to  n  data  items.  Each  decision  data  point  represents  a  point  in 
time.  Multiple  decisions  related  to  a  need  may  not  occur  at  the 
same  instance 

•  Results  occurring  over  time  as  related  to  a  decision  outcome  may 
be  represented  by  1  to  n  items  Result  may  be  considered  positive 
or  negative  data  items  as  identified  over  a  period  of  time 
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The  concept  of  the  NDR  is  predicated  on  the  ability  to  capture  and  make 
use  of  static,  incremental  information  in  a  dynamic  environment  such  as  decision 
making  In  the  sequence  of  elements  beginning  with  a  need  and  ending  with 
potentially  multiple  outcomes,  a  common  occurrence  is  how  decision  makers 
handle  changing  needs  over  time.  The  need  which  triggered  one  or  more 
decisions  and  results  may  have  evolved  due  to  modified  conditions  or  other 
circumstances.  Therefore,  for  the  framework  to  sufficiently  support  changing 
conditions,  an  assumption  must  be  made  in  the  relationship  among  the  need,  the 
decisions,  and  results  where  the  need  itself  remains  constant  throughout  the 
relationship  As  constraints  and  other  decisions  impact  the  concept  processes, 
events  must  be  evaluated  with  respect  to  the  original  "need"  from  which 
subsequent  actions  have  been  taken.  Questions  to  be  addressed  include  how 
associated  decisions  are  reactive  to  a  new  event  (such  as  an  engineering 
change  notices  placed  against  a  design)  impact  the  original  need).  If  the  need 
itself  changes  significantly,  a  new  NDR  linkage  is  required  since  the  previous 
relationship  links  are  not  longer  relevant  to  the  current  process  Within  the  new 
stream,  many  of  the  individual  elements  (such  as  some  of  the  decisions)  may  be 
similar  enough  (or  even  duplicate)  where  the  overall  impact  is  possibly  negligible 
However,  for  purposes  of  extracting  context  to  determine  the  impact  of  shifting 
needs,  the  NDR  streams  should  be  treated  independently. 
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Key  Decision  Attributes  -  Cost,  Timing,  and  Deliverables 

An  important  consideration  in  making  decision  data  applicable  for  future 
needs  is  determining  what  information  should  be  collected  Harvested  decision 
data  should  be  in  a  form  which  can  be  easily  leveraged  by  future  decision 
makers.  Early  determinations  of  what  may  be  relatively  useful  must  start  at  the 
time  the  decision  is  being  made  and  captured.  Information  to  be  added  to  the 
decision  context  includes  determining  what  were  important  decision 
considerations,  what  information  made  one  alternative  better  than  another,  and 
identification  of  the  risks  that  mattered  at  the  time  of  the  decision? 

Additionally,  harvesting  information  not  typically  included  or  easily 
extracted  in  the  decision  making  process  is  a  challenging  and  complex  problem. 
Issues  include  how  some  decision  makers  cannot  (or  will  not)  devote  time  to 
document  their  thinking  and  rationale  properly,  the  concern  of  overburdening 
decision  makers  with  information  capture  to  the  point  where  the  activity  becomes 
burdensome  and  resisted,  and  focus  on  collecting  information  having  no  future 
value  in  decision  making  activities 

Therefore,  a  set  of  common  criteria  must  be  established  for  both  the 
decision  maker  and  future  benefactors  of  the  decision  information.  Ideally,  the 
person  making  the  decision  would  know  best  how  to  evaluate  the  decision 
against  the  criteria.  Because  few  (if  any)  decisions  are  identical,  future 
benefactors  would  need  the  same  criteria  to  locate  past  information  that  may 
have  relevance  to  their  decision  making  tasks. 
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The  criteria  itself  is  made  up  of  three  core  elements  -  cosf,  timing  and 
deliverable .  Costs  are  related  to  financial  indicators,  including  decisions  impacts 
on  target  goals  or  changes  from  original  intentions.  Timing  is  related  to 
completion  of  an  item  with  relation  to  a  schedule  of  events  Deliverables  are 
expected  or  realized  outcomes  from  a  process  activity.  Data  should  be 
evaluated  with  an  eye  towards  how  the  criteria  influenced  decisions 

There  are  sound  reasons  for  employing  a  selective  approach  to 
harvesting  decision  information  First,  it  is  exceedingly  difficult  to  capture  within 
computer  tools  meaningful  input  on  the  individual  tradeoffs  and  thought 
processes  a  decision  maker  goes  through  In  terms  of  rationalization,  the  human 
mind  far  exceeds  technology  in  its  ability  to  make  multi-faceted,  non-linear 
decisions  [117].  Unfortunately,  technology  limitations  -  specifically  the  time 
required  to  capture  content  -  makes  it  virtually  impossible  to  sufficiently  detail 
decision  elements  in  a  form  to  allow  extraction  for  future  use.  Therefore, 
attempting  to  define  a  highly  granular  level  of  information  beyond  the  basic  costs, 
timings,  and  deliverables  is  not  realistically  possible.  At  an  aggregate  level  an 
avenue  for  identifying  trends  from  bulk  decision  data  would  be  through  data 
mining.  Data  mining  is  the  extraction  of  hidden  information  from  databases 
[118] 

Second,  "too  much”  data  can  have  an  adverse  affect  on  both  usage  and 
the  ability  to  leveraging  past  decision  data.  Decision  makers  faced  with 
reviewing  a  very  large  set  of  information  may  overlook  important  items  pertaining 
to  the  decision.  Overwhelming  a  decision  maker  with  vast  amounts  of  decision 
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data  (even  filtered)  can  cause  an  effect  generally  referred  to  as  the  “law  of 
diminishing  returns”  [117]. 
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ELEMENT  3  -  ORGANIZATION  OF  DATA  ELEMENTS  BASELINED  AROUND 
A  ROBUST  PRODUCT  DEVELOPMENT  PROCESS 

When  considering  the  use  of  applied  computer  applications  to  improve 
product  development,  organizations  should  baseline  on  generic  processes 
proven  successful  and  add  process  elements  which  are  fundamentally  unique  to 
the  business.  As  observed  in  the  survey  results,  organizations  involved  with 
concept  development  have  some  levels  of  processing  involving  computer-based 
information  systems  While  some  organizations  use  ’reengineering’  efforts  in 
conjunction  with  system  deployments,  others  choose  to  essentially  encode 
existing  processes  into  computer  systems  which  may  limit  effectiveness  of  the 
collaborative  technology  Therefore,  using  a  CSCW  implementation  period  to 
introduce  well-accepted  processes  into  an  organization  is  a  way  to  improved 
efficiency. 

As  previously  mentioned,  an  influential  product  development  framework 
has  been  published  by  Karl  Ulrich  and  Steven  Eppinger  [2]  The  process, 
formally  called  the  Product  Design  and  Development  (PDD)  process,  divides  the 
numerous  activities  of  product  creation  into  six  major  phases  Although  each 
phase  represents  an  important  step  in  the  formation  of  a  product,  it  is  the 
amount  of  guidance  provided  in  the  "up  front”  concept  development  phase  that 
makes  the  PDD  an  ideal  candidate  as  the  starting  point  for  standardizing  on  a 
product  development  methodology.  Information  used  for  decision  making  in  the 
concept  development  phase  of  the  PDD  is  supplied  by  a  multidisciplinary  team 
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representing  all  major  functions  of  an  organization,  including  marketing,  design, 
and  manufacturing. 

The  Ulrich  and  Eppinger  concept  development  phase  specifies  seven 
core  activities  -  Identifying  customer  needs,  establishing  target  specifications, 
concept  generation,  concept  selection,  concept  testing,  final  specifications,  and 
product  planning  Taken  in  whole,  the  purpose  for  the  concept  development 
phase  is  to  oversee  the  translation  of  initial  requirements  and  specifications  into 
concepts  [2]. 

From  the  perspective  of  the  framework  methodology,  the  use  of 
standardized  processes  provides  further  support  for  filtering  past  data  and 
decisions  to  bring  the  most  relevant  information  forward  Similar  to  the  cost, 
timing,  and  deliverable  criteria  previous  introduced,  using  standardized 
processes  allows  data  to  be  consistently  applied  for  multiple  concepting 
scenarios 

Introducing  change  to  existing  product  practices  requires  acknowledging 
that  short  term  difficulties  may  occur.  Although  an  organization’s  management 
team  may  support  leveraging  standardized  processes  as  agents  of  change,  it  is 
up  to  project-level  personnel  to  ensure  successful  application.  Therefore, 
focusing  appropriate  resources  and  energies  toward  end  user  adoption  is 
needed  to  allow  the  CSCW  system  to  become  an  agent  for  change  for  the 
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ELEMENT  4  -  INTEGRATE  RISK  ASSESSMENT  PROVIDING  AWARENESS 
TO  SPECIFIC  DATA  POINTS  THAT  COULD  HAVE  RELEVANCE  TO  A 

DECISION 

The  final  recommendation  in  the  framework  is  to  integrate  risk  tools 
directly  into  the  decision  data  sources.  Risk,  in  its  basic  definition,  is  the 
potential  harm  arising  from  an  unknown  future  event  [103].  As  discussed  in 
Chapter  2,  the  realm  of  risk-related  topics  and  research  is  extensive.  In  order  to 
narrow  the  scope  of  risk  topics  into  a  tangible  element  of  the  framework,  the 
sources  and  applications  of  risk  will  be  constrained  to  items  in  the  space 
managed  within  the  CSCW  environment. 

The  range  of  risk-related  tools  and  applications  is  widespread  in  theory 
and  practice.  Numerous  contributors  have  documented  successful  applications 
of  risk  tools  to  many  areas  of  product  development,  including  cost  estimating, 
timing,  production  planning,  and  alternative  selection  [107] 

The  goal  is  to  provide  a  general  awareness  for  potential  risk  items  based 
on  the  identification  of  specific  data  points  at  the  same  time  as  NDR  data  is 
presented  to  the  decision  maker.  In  this  manner,  direct  correlation  can  be  drawn 
between  decisions  and  mitigating  factors  which  may  require  additional 
consideration  Additionally,  a  complete  review  of  how  past  concepts  and 
decisions  have  faired  against  known  risks  over  time  may  be  accessible. 

Within  this  element,  the  same  filtering  guidelines  called  out  elsewhere  to 
identify  relevant  artifacts  and  past  decisions  can  be  used  to  filter  risk  items 
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related  to  cost,  timing,  and  deliverables.  Additionally,  other  criteria  (recalls, 
warranty  costs,  etc.)  can  be  applied  to  extract  relevant  risk  information. 


66 


CHAPTER  4  -  APPLICATION 

With  the  framework  defined  the  four  elements  were  being  applied  to  a 
suitable  reference  target  to  gauge  overall  effectiveness  of  the  methodology  In 
this  chapter,  identification  of  a  research  target  and  the  process  of  developing  a 
CSCW-based  prototype  environment  leveraging  the  principles  of  the  framework 
will  be  described.  The  results  of  using  the  prototype  in  two  case  studies  will  be 
presented  in  the  next  chapter. 
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RESEARCH  TARGET-  U.S.  ARMY  ADVANCED  CONCEPTS  TEAM  AND  THE 
FUTURE  TACTICAL  TRUCK  SYSTEM  (FTTS) 

The  Advanced  Concepts  Team  (ACT)  is  an  organization  within  the  United 
States  Army  Tank-Automotive  Research,  Development,  and  Engineering  Center 
(TARDEC),  whose  mission  is  to  field  technologies  to  will  sustain  the  Army  as  the 
world’s  premier  land-based  military  force.  TARDEC  responds  rapidly  to  changing 
battlefield  parameters  by  integrating,  maturing  and  demonstrating  emerging 
technologies  [119]. 

Located  in  Warren,  Michigan,  the  Advanced  Concepts  Team  is  housed  on 
the  grounds  of  the  U.S.  Army  Tank-automotive  and  Armaments  Command 
(TACOM)  TACOM  is  a  major  research,  development,  and  sustainment 
organizations  for  land-based  vehicle  systems  [120].  TACOM  has  a  rich  history 
as  a  key  developer  and  manufacturer  of  tanks  and  ground  vehicles  since  World 
War  II,  including  the  Ml  family  of  tanks  [121], 

The  role  of  the  Advanced  Concepts  Team  (ACT)  is  to  work  with  military 
organizations  to  develop  viable  concepts  from  defined  requirements.  The  ACT 
team  is  made  up  of  engineers  and  scientists  having  over  500  years  of  combined 
experience,  allowing  decision  makers  to  draw  knowledge  and  insight  directly 
from  the  team  [122],  Typically,  the  ACT  develops  a  variety  of  studies  and 
concept  designs  incorporating  physical  characteristics  into  concepts  using 
feature-based  requirements  The  ACT  concept  products  are  in  the  form  of  digital 
mockups,  animated  models,  desktop  solid  models,  simulations,  and  documents 
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providing  levels  of  performance  prediction  indication  in  the  areas  of  weight,  cost, 
survivability,  vulnerability,  mobility,  transportability,  lethality,  power,  and  overall 
performance  [123] 

ACT  Concept  Development  Process 

The  concept  development  process  employed  by  the  Advanced  Concepts 
Team  (ACT)  has  many  similarities  to  the  generic  process  described  by  Ulrich 
and  Eppinger  [2].  Based  on  interviews  and  reviews  of  documentation,  the  core 
elements  of  the  ACT  concept  development  process  can  be  summarized  below. 

1 .  A  request  is  made  from  an  Army  program  to  engage  the  ACT  in  a 
concept  activity.  In  some  cases,  the  concept  work  is  related  to  an 
entirely  new  class  of  vehicle,  while  in  other  cases  it  is  modification 
or  variation  of  an  existing  program 

2.  A  joint  investigation  and  requirements  analysis  is  conducted  for  the 
concept  involving  the  program  customer  and  the  ACT 

3  Leveraging  existing  information  from  internal  databases,  initial 
concepts  and  technology  surveys  are  generated. 

4.  A  Quality  Function  Deployment  analysis  is  conducted  on  the 
concept  information  to  identify  control  areas,  overall  targets,  and 
risk  areas. 

5  Through  an  iterative  process,  development  of  an  initial  concept 
design  with  a  series  of  target  metrics  is  developed  The  customer 
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provides  feedback  on  concept  areas  viewed  favorably  (or 
unfavorably).  In  some  cases,  additional  or  modified  requirements 
are  extracted  from  the  sessions. 

6.  A  series  of  specific,  detailed  concepts  based  on  initial  concept 
targets  and  designs  are  development  by  the  ACT. 

7.  The  concepts  are  reviewed  by  the  customer  during  a  formal 
concept  design  review.  Concepts  that  are  approved  move  forward 
for  further  detailed  analysis  to  include  areas  such  as  operational 
modeling,  mobility  modeling,  and  cost  analysis. 

8.  The  approved  concept  and  supporting  information  is  released  as 
an  Advanced  Concept  Technology  Demonstration  (ACTD), 

The  ACTD  typically  results  in  the  development  of  a  fully  functional 
prototype  to  demonstrate  the  production  feasibility  of  the  concept  The 
outcomes  from  the  ACTD  may  include  an  approval  to  field  the  technology,  a 
decision  to  terminate  the  program,  or  a  decision  to  move  forward  with  elements 
of  existing  technology  in  conjunction  with  (or  in  place  of)  the  demonstrated 
prototype  [124], 

Future  Tactical  Truck  Systems  (FTTS) 

The  ACT  has  been  working  for  on  a  major  land  vehicle  development 
program  known  publicly  as  the  Future  Tactical  Truck  System  (FTTS).  The  goal 
of  the  FTTS  program  is  to  develop  a  series  of  "sustainment"  vehicles  to  support 
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all  types  of  engagements  conducted  In  a  modern  military  theater.  FTTS  vehicles 
are  intended  to  address  shortfalls  exhibited  by  the  existing  fleet  of  military 
transports  due  to  an  outdated  architecture  requiring  multiple  variants,  a 
cumbersome  logistics  footprint,  poor  C-130  deployability,  poor  fuel  economy, 
mobility  limitations,  and  incompatibility  with  newer  Army  technology  systems 
[125], 

The  FTTS  program  has  concentrated  on  creating  only  two  core  "variants" 
for  the  program- 

•  A  "Utility  Vehicle"  designed  for  a  payload  of  up  to  3  tons  under  a 
basic  4x4  wheel  operation.  Variants  falling  within  this  vehicle  class 
include  light  armor  command  and  control  vehicles,  general  utility 
trucks,  and  ambulances  [125] 

•  A  larger,  delivery-based  transport  known  as  the  Maneuver 
Sustainment  Vehicle  (MSV)  with  a  payload  capacity  of  13  tons  to 
streamline  distribution  of  cargo,  equipment,  and  personnel.  [125] 

The  Maneuver  Sustainment  Vehicle  (MSV)  provides  a  number  of 
important  technological  advances  aimed  to  reduce  maintenance,  provide  more 
features  and  capabilities,  and  deliver  payload  elements  without  the  need  for 
specialized  or  external  material  handling  equipment  (MHE)  [125],  Key  FTTS 
vehicle  technology  advances  include: 
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•  Increased  fuel  efficiency  with  extended  delivery  ranges  of  600  to 
900  miles 

•  100%  communication  support  to  improve  supply  delivery  accuracy 
and  eliminate  unnecessary  re-supply  activities. 

•  Intelligent  load  handling  systems. 

•  Capable  of  transporting  equipment,  NATO  flat  racks,  varied 
mission  supplies  (fuel,  water,  ammunition,  and  other  cargo)  and 
standardized  containers 

Research  Applications 

Through  analysis  of  the  processes  and  activities  undertaken  by  the 
Advanced  Concepts  Team,  two  opportunities  emerged  for  application  of  the 
framework  leveraging  the  FTTS  MSV  concept.  The  first  opportunity  involved  the 
recreation  of  a  design  review  undertaken  during  the  FTTS  MSV  concepting 
phase.  The  second  opportunity  was  based  on  studying  a  new  concept 
component  designed  specifically  for  the  FTTS  MSV,  a  multi-purpose  crane. 

The  first  opportunity  represented  a  broader  application  of  the  framework 
methodology,  while  the  second  opportunity  was  much  more  focused  but  touched 
more  elements  of  the  framework.  While  both  opportunities  are  related  to  the 
FTTS  MSV,  each  is  distinct  enough  to  be  handled  with  separate  treatments 

The  approach  taken  to  describe  how  the  framework  was  applied  will  be  to 
first  provide  an  overview  of  the  opportunities  with  focus  on  the  specific  areas  of 


interest  The  remainder  of  the  discussion  will  describe  the  elements  of  a 
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prototype  developed  to  support  the  research  opportunities.  Results  and  analysis 
of  the  treatments  will  be  provided  in  subsequent  chapters. 

Study  I:  Concept  Design  Review 

One  of  the  milestone  events  during  FTTS  MSV  concepting  activities  was  a 
lengthy  design  review  session  conducted  over  consecutive  days.  The  session 
was  focused  on  bringing  together  experts  from  various  application  teams  to 
review  the  complete  MSV  conceptual  design,  collaborate  on  ideas  for 
improvement,  and  emerge  from  the  session  with  an  improved  concept.  The 
design  review  occurred  in  2003  at  the  Advanced  Concept  Team  offices. 
Representatives  include  various  participants  from  the  Army  R&D  community, 
Army  Officers  involved  with  managing  the  MSV  program,  and  key  contractors 
and  industry  partners. 

Review  Process 

The  first  phase  of  the  review  was  to  identify  a  set  of  critical  success 
factors  for  the  MSV  concept  formally  called  "Standards  of  Excellence".  These 
standards  were  comprised  of  general  Army  tenets  (e.g.  "Soldier  First"  -  comfort, 
safety,  accessibility,  ergonomics,  and  maintainability)  along  with  specific  metrics 
and  targets  in  the  areas  of  survivability,  vulnerability,  designs,  and  materials. 

Once  the  standards  were  identified,  each  major  subsystem  within  the 
MSV  was  reviewed  by  the  entire  design  team.  The  process  involved  a  facilitator 
leading  a  review  of  the  subsystem  with  discussion  in  the  form  of  questions, 
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challenges,  and  suggestions  from  the  assembled  team  During  each  discussion, 
a  1/6  scale,  table-size  model  was  used  to  arrange  how  major  subsystems  were 
to  be  placed  within  the  MGV  Additionally,  as  changes  were  suggested  from  the 
review  panel,  modifications  were  applied  to  3D  renderings  of  the  MSV  displayed 
on  a  projection  screen  to  allowed  proposed  changes  to  be  viewed  in  real-time. 
Combined,  the  desktop  model  and  projected  visualization  of  the  concept 
provided  the  review  team  with  a  compelling  set  of  data  to  evaluate  possible 
configuration  changes  for  the  MSV  concept 

Outcomes 

Several  recommendations  from  the  concept  review  session  were 
incorporated  directly  into  the  FTTS  MSV  designs  Among  the  more  relevant 
modifications  to  the  MSV  concept  included  the  following  recommendations: 

•  Inclusion  of  a  large  panel  in  the  front  of  the  MSV  to  allow  easier 
access  to  the  engine  compartment. 

•  Separation  of  the  fuel  tank  into  two  containers. 

•  Improved  ergonomics  and  accessibility  to  the  communications 
module  through  relocation  of  the  components. 

•  Modified  location  and  functionality  of  a  "self  defense"  protection 
weapon 

•  Recommendations  for  external  storage  of  ammunition. 
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•  Powertrain  exhaust  routing  through  the  rear  of  the  MSV  (the  initial 
concept  routed  exhaust  through  the  side  of  the  vehicle) 

Additional  performance  information  discussed  and  captured  from  the 
review  was  incorporated  into  the  MSV  ACTD  performance  specification.  Further, 
a  "compliance  matrix"  was  developed  to  compare  concept  targets  to  prototype 
metrics  upon  completion  of  the  detailed  designs  and  prototype.  Figure  4  1 
displays  a  graphical  representation  of  the  FTTS  MSV  concept  (Source.  U  S. 
Army  Public  Release  Presentation). 


Figure  4.1  FTTS  MSV  Concept 
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Relevance 

The  FTTS  MSV  design  review  represents  a  single  point  in  time  where  key 
decision-makers  and  experts  met  together  to  openly  collaborate  on  improving  the 
concept.  The  expert  interaction  among  decision-makers  represents  “the 
pinnacle"  of  information  assessment  to  make  sound  concept  decisions. 

Research  Application  Opportunity 

The  interchange  that  occurred  between  key  program  players  provided  a 
level  of  insight  to  relevant  factors  important  for  capture  in  a  decision-support 
framework  Using  data  points  from  the  review  (process,  component  decisions, 
and  relevant  inputs),  the  CSCW  prototype  attempted  to  simulate  the  concept 
review  process  to  provide  a  decision  maker  with  relevant  information  to  possibly 
influence  the  action  similar  to  an  expert  who  participated  in  the  review  session. 
Specifically,  the  approach  was  to  use  the  framework  to  create  a  prototype  to 
support  concept  decision  making  by  mapping  data  similarities  through  comparing 
attribute  information  on  an  ACT  data  set,  simulated  past  decisions,  and  other 
relevant  data  points. 

Study  II:  Multi-Purpose  Crane 

An  important  concept  emerging  from  the  FTTS  MSV  design  was  a  multi¬ 
purpose  crane  providing  a  variety  of  cargo  processing  operations  currently 
handled  by  several  different  pieces  of  equipment.  The  multi-purpose  crane 
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allows  the  MSV  vehicle  to  completely  back  up  into  target  transport  aircraft  (e  g. 
C-130),  remove  cargo  off  the  plane,  and  provide  capabilities  similar  to  a  forklift  to 
move  and  arrange  cargo  (either  onto  a  vehicle,  ground,  or  other  equipment), 

Background 

Although  the  MSV  multi-purpose  crane  was  an  original  concept,  the 
origins  of  the  concept  were  based  in  part  on  the  realization  of  non-FTTS 
requirements  and  information  from  precursor  vehicle  systems.  Requirements 
contributing  to  the  crane  originated  from  a  broad  Army-wide  initiative  directed  at 
streamlining  systems  and  reducing  the  amount  of  material  handling  equipment 
(MHE)  used  for  cargo  handling.  The  multi-year  initiative  known  as  SMART 
(Simulation  and  Modeling  for  Acquisition,  Requirements,  and  Training)  has  the 
goals  of  reducing  the  time,  resources,  and  risk  associated  with  the  acquisition 
process  while  increasing  the  quality  and  supportability  of  fielded  systems  [127] 

Another  contributor  to  FTTS  MSV  multi-crane  concept  is  the  palletized 
load  system  (PLS)  currently  deployed  in  several  configurations  on  the  Army’s 
HEMTT-class  (Heavy  Expanded  Mobility  Tactical  Truck)  transport  vehicles  The 
PLS  consists  of  a  rear-mounted  material  handling  crane  (MHC)  with  the  ability  to 
“hook  and  pull”  standardized  containers  and  pallets  back  onto  itself  Figure  4.2 
provides  a  view  of  the  PLS  system  on  a  M1076  HEMTT  with  a  16  5  ton  payload 
(Source:  U  S,  Army  Public  Release) 
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Figure  4.2  HEMTT  PLS  Loading  a  Standard  Container 


Relevance 

The  FTTS  MSV  smart  crane  extends  beyond  the  singular  capabilities  of 
the  HEMTT  PLS  "hook  and  pull"  concept  by  providing  the  ability  to  lift  and 
arrange  pallets  through  the  addition  of  lifting  arms  analogous  to  standard  forklift 
functionality.  The  additional  functionality  allows  cargo  to  be  loaded  and  carefully 
arranged  either  onto  the  MSV  or  to  other  cargo  vehicles  The  FTTS  MSV  multi¬ 
purpose  crane  also  has  several  pre-programmed  motion  sequences  to  allow  the 
device  to  be  quickly  extended  to  certain  distances  without  having  an  operator 
control  every  element  of  the  sequence  Additionally,  the  FTTS  MSV  is  designed 
with  a  "variable  height"  suspension  to  allow  the  chassis  to  adjust  to  different 
levels  as  needed  to  manipulate  cargo  (such  as  elevating  to  the  height  of  C-130 
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decks)  The  FTTS  MSV  multi-purpose  concept  crane  is  shown  in  a  rendenng  in 
Figure  4.3  (Source  -US  Army  Public  Release) 


Figure  4.3  FTTS  MSV  Multi-Purpose  Crane 

The  FTTS  MSV  multi-use  crane  is  intended  to  improve  loading  and 
unloading  time  by  reducing  the  need  for  additional  pieces  of  equipment,  reduced 
maintenance  times  and  costs  (on  individual  MHE  systems  like  the  K-loader  and 
forklifts),  and  reduction  of  the  number  of  necessary  personnel  for  material 
handling  Because  a  transport  airplane  may  be  force  to  land  in  a  "hot  spot"  e  g, 
an  active  military  theater,  current  MHE  equipment  such  as  K-loaders  and  forklifts 
may  not  be  suitable  for  manipulating  cargo.  Therefore,  the  MSV  multi-use  crane 
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allows  equipment  to  be  moved  in  locations  previously  not  possible  with  standard 
MHE  equipment.  Currently,  the  FTTS  MSV  multi-purpose  crane  is  being 
produced  in  fully-functional  prototypes  by  Stuart  &  Stevenson,  a  defense 
contractor  [128] 

Research  Application  Opportunity 

The  FTTS  MSV  multi-purpose  crane  provided  a  specific  example  where 
requirements  combined  with  contributions  from  existing  systems  can  be  used  in 
the  development  of  a  successfully  concept.  Similar  to  the  method  taken  with  the 
FTTS  MSV  concept  design  review  study,  the  approach  for  applying  the 
framework  model  to  the  multi-purpose  crane  was  to  create  a  prototype  to 
simulate  the  concepting  activities  and  provide  potentially  important  data  to  a 
decision  maker  through  data  filtering 
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CSCW  PROTOTYPE  DEVELOPMENT 

Upon  identifying  targets  for  application  of  the  research,  the  process  of 
developing  a  prototype  environment  based  on  the  core  elements  of  the 
framework  was  undertaken.  Development  of  the  prototype  followed  each  of  the 
core  elements  in  the  preferred  order  of  application. 

Identification  of  Core  CSCW  Environment 

The  first  step  in  the  creation  of  a  prototype  was  the  selection  of  an 
appropriate  CSCW  software  environment  to  serve  as  the  foundation  for  the 
framework  architecture  Functionality  from  commercially  available  software 
systems  that  could  be  leveraged  as  a  prototype  foundation  can  be  found  in 
Document  Management  Systems  (DMS)  such  as  Documentum  and  Adobe, 
Business  Process  Management  (BPM)  such  as  BEA  and  Sterling,  portal 
environments  such  as  Microsoft  SharePoint  and  IBM  WebSphere,  and  Product 
Lifecycle  Management  (PLM)  system  [129]  Additionally,  tools  such  as  Wiki's 
are  gaining  popularity  as  collaboration  environments  as  teams  move  toward 
"openly-managed"  approaches  to  information  sharing  [130].  For  this  research, 
the  commercial  application  Windchill,  a  PLM  architecture  from  PTC,  was 
selected  for  use  as  the  CSCW  prototype  architecture.  Windchill  provides  the 
ability  to  create  and  organized  a  data  schema  based  on  an  object-oriented 
hierarchy  and  metadata  [131]. 
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The  choice  of  the  Windchill  architecture  also  served  to  facilitate  selection 
of  several  other  required  CSCW  components.  The  Windchill  environment 
natively  'bundles'  several  software  products  with  functionality  previously  identified 
that  is  necessary  to  support  the  CSCW  architecture,  including  a  search  engine, 
Web  services,  and  process  standardization  tools.  The  CSCW  system  based  on 
the  Windchill  environment  was  deployed  onto  a  single,  Windows-based 
computer  system.  The  framework  architecture  after  deployment  is  represented 
in  the  diagram  provided  in  Figure  4  4  (source  -  PTC). 


Windchill  System  Components 


Dntab*«e 

Tl«*r 


Figure  4.4  CSCW  Framework  Architecture 


Upon  deployment  of  the  architecture,  additional  configuration  focused  on 
the  creation  of  attributes  for  capturing  metadata  for  use  in  filtering  decision- 


based  information. 
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Data  Characteristics  and  Hierarchy 

As  previously  described,  another  important  activity  within  framework 
deployment  involved  identifying  a  data  hierarchy  for  managing  concept  related 
information.  The  approach  used  was  to  analyze  the  information  to  be  managed 
within  the  prototype  and  propose  a  hierarchy  to  optimize  data  storage  and 
access  A  prerequisite  activity  was  to  understand  the  information  mass 
managed  by  the  Advanced  Concepts  Team  (ACT)  The  ACT  has  implemented  a 
variety  of  data  storage  and  3-D  information  systems  facilitating  full-range 
modeling  and  concepting  activities.  Among  core  tools  use  for  information 
management  within  the  ACT  is  the  Advanced  Collaborative  Environment  (ACE). 
The  ACE  is  a  portfolio  of  design  tools  based,  in  part,  on  a  Windchill  environment 
and  used  to  manage  concept  information  (designs,  documents,  and 
presentations)  [132]. 

An  assessment  of  Advanced  Concept  Team  information  managed  with 
ACE  revealed  approximately  2800  ACT  unclassified  data  items.  Data  items 
included  legacy  requirements,  concept  information,  renderings,  models,  test 
data,  academic  papers  and  trade  studies.  Also  managed  within  the  ACT  data 
environment  were  a  large  number  of  data  items  appearing  to  have  no  value 
within  the  reuse  principles  being  proposed  -  biographical  statements,  maps, 
agendas,  forms,  organization  procedures,  and  non-work  related  information 
Finally,  a  substantial  amount  of  duplicated  (or  near-duplicated)  information  was 
identified  within  the  data  set  Using  a  subset  of  the  information  representing  the 
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most  relevant  data  to  the  framework,  a  data  set  consisting  of  approximately  900 
items  was  extracted  for  use  within  the  prototype  environment. 

Historically,  the  Advanced  Concepts  Team  has  not  relied  on  workflow- 
related  decision  processing  for  concept  development  and  approval  activities. 
Therefore,  very  little  explicit  ACT  "decision-related”  data  was  identified  in  the 
ACE  environment  -  which  was  expected  since  most  organizations  do  not 
historically  capture  past  decision  points  in  a  manner  which  would  facilitate  direct 
reuse.  Although  the  lack  of  explicit  decision  data  impacted  the  prototype  from 
the  perspective  of  transparent  correlation  to  the  root  data  set,  the  volume  of 
information  extracted  from  the  ACT  subset  still  provided  a  robust  test  bed  for 
analysis. 

Another  important  element  of  the  ACT  data  analysis  was  a  review  of  the 
existing  categorization  structure  and  hierarchy  in  the  ACE.  The  'state'  of  the  data 
hierarchy  revealed  a  large  number  of  information  stores  that  have  grown  fairly 
'organically'  over  time  -  meaning  the  data  structure  appeared  to  evolve  over  time 
with  localized  (non-holistic)  planning  for  data  management.  A  generic 
representation  of  the  ACT  information  hierarchy  is  shown  in  Figure  4.5.  Due  to 
the  sensitive  nature  of  the  data  leveraged  by  the  ACT,  the  categories  shown  in 
Figure  4.5  have  been  generalized. 

As  previously  described,  the  structure  of  the  CSCW  information  hierarchy 
becomes  an  important  element  in  the  ability  to  extract  relevant  information  for 
the  decision  maker  Considered  in  aggregate,  the  Advanced  Concepts  Team 
information  hierarchy  managed  within  ACE  supports  opportunities  to  provide 
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details  on  concepts  which  could  as  reference  to  the  team  In  the  observed  state, 
the  data  hierarchy  showed  substantial  information  category  overlap,  redundancy, 
and  inconsistency  among  topics  -  which  has  probably  hindered  the  use  of 
historical  data  among  the  team  As  represented  in  Figure  4.5  with  the  summary 
representation  of  the  ACT  data  hierarchy,  duplicate  classes  of  information  exists 
in  different  locations  (e  g  studies,  modeling  and  simulation  data,  conference  and 
technology  briefings,  photographs,  videos).  Based  on  the  interpretation  of  the 
survey  data  discussed  in  Chapter  3,  one  conclusion  of  the  analysis  can  be 
finding  or  discovering  relevant  ACT  information  should  be  improved  through 
adoption  of  the  framework  principles  outlined  in  this  research. 
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Figure  4.5  Representation  of  Existing  ACT  Data  Hierarchy 
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Using  the  hierarchy  analysis  as  a  basis,  the  CSCW  prototype  was 
designed  with  an  approach  for  managing  information  stores  using  a  "matrixed" 
construct.  As  described  in  Chapter  3,  the  characteristics  of  the  data  itself 
provided  a  path  for  determining  a  structure  The  existing  hierarchy  can  be 
divided  into  two  categories  based  on  either  entity  or  descriptive  characteristics. 
From  the  entity  perspective,  three  major  categories  of  data  were  identified  based 
on  the  ACT  data  characteristics  analysis: 

•  Programs  such  as  the  Future  Tactical  Truck  System  (FTTS) 

•  Concepts  as  related  to  specific  military  systems  or  subsystems  (in 
a  fielded,  prototype/experimental,  or  "future  needs"  state  of 
development). 

•  Technologies  for  use  within  concepts  (such  as  materials  and 
powertrain  fuels). 

From  the  descriptive  perspective,  two  major  categories  of  information 
were  identified 

•  Details  -  Program-related  data  typically  classified  as  requirements, 
program  management  documents,  specifications,  etc 

•  Characteristics  -  Types  of  studies  conducted  on  concepts  or 
programs  (e  g.  survivability,  weight,  maintainability). 
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The  major  categories  and  key  sub  categories  of  the  ACT  data  set  is 
provided  in  Figure  4  6,  Additionally,  classes  of  information  related  to 
conferences,  industry  briefings,  and  academic  events  are  also  accounted  for 
among  the  categories. 
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Figure  4.6  Major  Categories  and  Sub-Categories  of  the  CSCW  Prototype 


As  mentioned  in  Chapter  3,  representing  a  matrixed  data  hierarchy  can  be 
complicated  within  a  computer  environment  more  suited  to  a  simple,  top-down 
data  hierarchy.  Although  a  matrixed  hierarchy  can  be  implemented  through  the 
use  of  proxy  references  (such  as  pointers  and  links)  so  data  is  not  physically 
replicated,  transposing  a  portion  of  the  matrix  into  a  traditional  hierarchy  provided 
for  better  traversing  and  maintenance.  Therefore,  within  the  prototype  several 
descriptive  categories  (related  to  Details  and  Characteristics)  were  transposed 
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as  subordinate  to  the  entity  categories  Although  the  transposed  structure  did 
create  duplicate  sub-categories  in  the  literal  sense,  the  uniqueness  of  the  higher- 
level  categories  eliminated  problems  of  duplicating  or  miscategorizing  data 
items.  Figure  4.7  provides  a  partial  view  of  the  transposed  data  hierarchy  as 
displayed  from  the  CSCW  prototype. 


Figure  4.7  Transposed  Data  Hierarchy  within  the  CSCW  Prototype 
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Content  Filtering  Attributes 

Content  filtering  attributes  provide  an  important  measure  for  identifying 
data  that  could  be  leveraged  to  assist  in  decision-making  activities  In  the  data 
subset  extracted  from  the  Advanced  Concept  Team  (ACT),  each  item  is 
managed  using  a  generic  set  of  metadata  attributes  such  as  a  title  and  short 
description.  With  a  generic  schema  there  are  few  opportunities  to  distinguish 
information  for  rapid  location  and  discovery,  and  identifying  specific  data  items 
therefore  relies  heavily  on  content  indexing  via  search  engines.  Within  the 
prototype,  several  attributes  were  added  into  the  data  hierarchy  for  each 
managed  item  as  indicators  for  possible  data  reuse.  The  list  of  extended 
attributes  included  the  following  metadata 

•  Program  or  Platform 

•  Concept  Type 

•  Vehicle  system  or  subsystem 

•  Analysis  Type 

•  Key  Outcomes 

•  Critical  Requirements 

•  Age/Relevancy  Period 

Of  the  attributes  listed,  “Age/Relevancy  Period”  provides  a  significant 
criterion  on  which  data  can  be  filtered  since  time  sensitivity  plays  an  important 
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role  for  data  relevancy.  Within  the  ACT  data  set,  technological  advances  have  a 
substantial  impact  on  concept  obsolescence.  However,  many  elements  from 
legacy  studies  and  concepts  (e.g.  munitions  studies,  vehicle  test  data,  motion 
studies)  still  can  provide  relevant  references  for  decision  makers. 


Process  Flows 

Advanced  Concepts  Team  process  flows  were  developed  within  the 
prototype  to  route  information  to  participants  based  on  pre-defined  work  patterns 
encompassing  the  overall  development  state  of  the  concept.  Within  the  CSCW 
environment,  work  processing  models  are  included  as  part  of  a  standard 
software  toolkit.  For  the  Advanced  Concepts  Team  development  process,  the 
core  steps  were  encoded  into  the  environment  in  the  form  of  discrete  tasks  as 
shown  in  Figure  4.8. 


Figure  4.8  CSCW  Prototype  Process  Map 
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General  comments  related  to  the  prototype  process  flow. 

•  The  process  initiator  (a  senior  team  member,  team  leader,  or 
manager)  determines  the  type  of  concept  activities  to  be 
undertaken.  Information  describing  the  concept  is  also  linked  to 
the  work  process.  Based  on  the  items  selected,  concept 
development  activities  in  the  form  of  tasks  are  assigned  to 
members  of  the  concept  community  Team  members  act  on  the 
assigned  tasks,  usually  creating  or  enhancing  information 

•  It  is  during  the  "in-house"  search  of  prior  concepts  or  related 
information  where  the  first  use  of  the  data  filtered  based  on  specific 
attribute  information  becomes  an  important  element  in  the 
generation  of  concepts.  Based  on  requirements  for  the  concept 
being  considered,  data  within  the  CSCW  environment  will  be  made 
available  to  the  developer  based  on  correlated  attribute 
information. 

•  Upon  completion  of  core  development  activities,  the  concept  is 
processed  through  a  series  of  reviews  with  internal  groups, 
customers  downstream  work  teams,  or  external  contractors 
working  with  the  program. 

•  As  concepts  mature  and  move  forward  toward  customer  approval 
and  ACTD,  it  is  at  this  stage  where  prior  decision  data  becomes 
relevant  to  the  reviewers  and  decision  makers.  Using  the  filtering 
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attribute  information  and  data  derived  from  the  three  core  decision 
artifacts  described  in  Chapter  3  (cost,  timing,  and  deliverables), 
reviewers  in  the  activity  chain  receive  past  decision  data  that  best 
corresponds  to  the  decision  in  hand  Reviewers  can  traverse 
returned  decision  objects  to  view  related  outcomes,  including 
effects  over  time. 

•  Ultimately,  a  decision  will  be  reached  on  the  concept  under 
development.  In  making  the  decision,  the  task  owner  provides 
information  related  to  the  core  criteria  that  helped  drive  the  decision 
forward.  The  data  captured  will  be  managed  on  the  decision 
object,  along  with  meaningful  links  to  items  that  best  represent  a 
data,  creating  a  narrative  over  time  describing  both  "up  to  the 
decision  point"  perspective  as  well  as  "what  happened  after"  history 
(prototyping,  production,  maintenance,  engineering  changes). 
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Development  of  the  Decision  Object 

The  decision  object  represents  a  common  holder  for  information  as  it 
pertains  to  the  decision.  Within  the  CSCW  environment,  object-related  data  that 
best  provides'  a  holistic  perspective  on  the  evolution  of  a  concept  includes 
documents,  parts,  products,  CAD  files,  and  engineering  changes.  It  is  assumed 
the  application  of  the  decision  object  is  transparent  to  the  specific  types  of 
objects  managed  within  the  CSCW  environment  Stated  another  way,  the 
decision  object  should  be  able  to  adapt  and  make  reference  to  the  object 
hierarchy  of  any  CSCW  environment  where  it  is  being  applied. 

As  described  by  Ulrich  and  Eppinger,  data  is  typically  more  subjective 
(specifications  and  requirements)  and  design  ’simplistic*  (renderings  and 
sketches)  in  the  concept  development  phase  than  in  later  phases  (where 
complex  CAD  designs  and  Bills  of  Material  representing  the  final  products  are 
used  extensively)  [2].  Therefore,  data  anticipated  for  use  in  a  new  concept 
decision-making  activity  will  likely  be  more  descriptive-based  than  math-based 
(CAD  and  3D  renderings).  Conversely,  once  a  concept  has  moved  into  later 
stages  of  product  development,  representative  data  elements  will  include  CAD 
data,  part  structures,  and  engineering  change  data 

Combined,  the  complete  descriptive  range  of  these  objects  represents  the 
life  cycle  of  a  product.  Within  this  framework,  it  is  presumed  decision  makers  will 
benefit  from  seeing  subjective  data  used  in  making  a  concept-related  decision  as 
well  as  the  results  -  the  effect’  -  of  the  concept  after  being  produced  and  fielded. 
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In  many  enterprise  environments,  much  of  the  data  representing  the  “success  of 
failure”  cf  a  fielded  concept  can  be  best  located  in  external  systems  such  as 
financial  databases,  warranty  claim  systems,  and  reliability  reports.  Product 
design-oriented  systems  can  leverage  design  revisions  like  engineering  changes 
for  similar  indicators  For  of  the  framework  prototype,  “result  indicators”  were 
confined  to  the  subset  extracted  from  the  ACT  data  system. 

In  the  context  of  the  prototype  CSCW  environment,  the  decision  object  as 
described  in  Chapter  3  was  design  to  provide  mechanisms  to  traverse  most,  if 
not  all,  of  the  core  object  types  (drawings,  photographs,  presentations).  In 
object-o'iented  application  development,  an  advantage  of  leveraging  an  object- 
based  hierarchy  is  the  ability  to  extend  a  base  object  having  existing  desired 
characteristics  in  order  to  supplement  with  specific,  intended  behavior  [133]. 

Within  the  Windchill  environment,  an  object  called  WTDocument 
(General  Document)  was  extended  using  UML  modeling  tools  to  provide  decision 
harnessing  capabilities  into  a  new  object  (called  "ConceptDecision"  or  "Decision" 
by  its  common  reference).  The  decision  object  was  extended  to  retain  three  core 
elements  captured  from  the  decision  -  cost,  timing,  and  deliverables  -  and  other 
attributes  described  in  Chapter  3  for  decision  and  content  filtering  (milestones, 
end  state,  etc  ).  Figure  4.9  provides  the  UML  diagram  of  extended  decision 
object  from  based  object  WTDocument. 
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Figure  4.9  Extended  Decision  Object  for  the  CSCW  Prototype 

A  key  behavior  ConceptDecision  directly  inherited  from  WTDocument  was 
the  ability  to  create  persistent  linkages  with  other  objects.  Additionally, 
ConceptDecision  can  have  relationships  with  workflow-based  objects 
(WTWorkflow)  where  specific  activity  and  action  information  is  persisted  The 
decision  object  (ConceptDecision)  was  designed  for  exposure  in  the  graphical 
user  interface  (GUI)  through  modification  of  existing  HTML,  JSP,  and  XML 
templates. 

Decision  and  Risk  Items  in  the  Prototype 

Within  the  prototype,  risk  will  be  measured  using  a  subjective  evaluation 
against  a  specific  target  decision  data  item  Although  it  is  plausible  that  using 
subjective  measures  are  not  nearly  effective  as  numerically-based  indicators,  the 
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returned  risk  items  in  the  CSCW  prototype  should  offer  an  additional  perspective 
on  outcome  to  concept  development  decision  makers. 

As  mentioned  earlier,  the  Advanced  Concepts  dataset  extracted  from 
ACE  did  not  have  explicitly  called  out  data  items  related  to  prior  decisions  or  risk 
elements  In  order  to  satisfy  the  need  for  having  decision  and  risk  data  within  the 
prototype  to  simulate  concept  decisions,  data  items  found  to  best  represent  an 
approximation  of  final  decision  were  entered  into  the  prototype  as  "decision 
objects”.  Similarly,  items  from  the  ACT  data  set  having  attribute  information  best 
resembling  a  problem  report,  issue,  or  change  were  entered  into  the  environment 
as  risk  items  Risk  items  created  within  the  prototype  included  engineering 
design  reports,  problem  reports  captured  from  the  field,  test  incident  reports  and 
external  items  such  as  articles,  trade  studies,  or  academic  papers. 

Decision  Advisor 

To  assemble  all  key  relevant  decisions,  data  items,  and  risk  elements 
together  into  a  format  that  can  be  quickly  leveraged  by  a  decision  maker  working 
a  concept  development  activity,  a  "Decision  Advisor"  module  was  developed. 
The  module  was  based  on  linking  formatted  outputs  of  several  independent,  but 
complex  data  queries  together  in  a  single  interface.  The  query  parameters  are 
based  on  passing  key  parameter  data  at  runtime  A  view  of  the  Decision  Advisor 
interface  is  provided  in  Figure  4  10 
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Figure  4.10  CSCW  Prototype  Decision  Advisor  interface 

Using  the  Decision  Advisor,  data  can  be  accessed  for  easy  reference  by 
the  decision  maker.  Figure  4  1 1  displays  output  from  the  advisor  for  decisions 
involving  the  FTTS  program. 
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Figure  4.11  CSCW  Prototype  Decision  Advisor  Filtered  Data  Report 
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CHAPTER  5  -  RESULTS  AND  ANALYSIS 

This  chapter  describes  outcomes  from  prototype  environment  simulations 
with  data  representative  of  the  case  studies  described  in  Chapter  4  The 
evaluation  approach  for  each  example  will  be  presented,  key  targets  for  analysis 
identified,  and  results  analyzed 

As  described  in  Chapter  4,  a  CSCW  prototype  was  developed  to 
demonstrate  the  feasibility  of  the  framework  in  a  concept  development 
environment.  Two  examples  from  the  U.S.  Army  Advanced  Concepts  Team 
(ACT)  specific  to  the  Future  Tactical  Truck  System  (FTTS)  Maneuverable 
Sustainment  Vehicle  (MSV)  were  identified.  The  CSCW  prototype  was 
developed  in  a  manner  consistent  with  the  principles  of  the  framework. 

The  case  study  simulations,  although  representative  of  the  same  concept, 
were  applied  in  two  different  manners.  In  the  first  case  study,  the  purpose  of  the 
experiment  was  to  locate  information  having  possible  relevancy  on  the  concept 
review  activity.  The  second  case  study  simulates  a  decision  making  activity  as 
related  to  an  aspect  of  the  MSV  concept  multi-purpose  crane.  All  data  used  in 
the  simulations  (from  the  ACT  data  subset)  excluded  content  developed  after  the 
period  of  the  FTTS  MSV  concept  development  phase  (approximately  2003  and 
beyond).  Using  FTTS  MSV  program  data  captured  since  original  concepting 
work  would  invalidated  the  intent  of  simulations  -  attempting  to  leverage  data  to 
make  concept-related  decisions. 
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CASE  STUDY  I:  CONCEPT  DESIGN  REVIEW 


A  formal  design  review  was  conducted  in  2003  on  the  Future  Tactical 
Truck  System  (FTTS)  Maneuverable  Sustainment  Vehicle  (MSV)  during  the 
concept  development  phase.  The  review  covered  all  system  and  subsystem 
concepts  of  the  MSV.  As  described  in  Chapter  3,  several  decisions  related  to 
important  modifications  to  the  MSV  concept  were  made  during  the  review  Using 
summary  reports  and  interview  information,  some  of  the  key  concepts  modified 
during  the  review  were  identified  for  use  in  the  framework  simulation 

Through  using  modified  concepts  elements  as  the  baseline,  the  approach 
for  the  prototype  simulation  was  be  to  identify  data  elements  from  the  extracted 
ACT  subset  that  correlate  to  the  concept  or  provide  relevant  perspectives  of  data 
possibly  useful  to  the  decision  maker  Six  simulated  targets  extracted  from  the 
MSV  design  review  are  summarized  below. 

1.  Inclusion  of  a  large  panel  on  the  front  of  the  MSV  to  allow  easier 
access  to  the  engine  compartment. 

2  Separation  of  the  fuel  tank  into  two  containers. 

3.  Improved  ergonomics  and  accessibility  to  the  communications 
module  through  relocation  of  components. 

4.  Modified  location  and  functionality  of  a  "self  defense"  protection 
weapon 

5.  Recommendations  for  external  storage  of  ammunition 
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6.  Powertrain  exhaust  routing  through  the  rear  of  the  MSV  (the  initial 
concept  routed  exhaust  through  the  side  of  the  vehicle). 

Using  the  CSCW  prototype,  data  from  the  ACT  subset  was  filtered  against 
the  simulation  targets  and  analyzed.  Tables  5  1  through  5  6  represent  the 
results  of  the  six  test  runs  to  extract  relevant  information.  In  each  table,  the  data 
set  includes  the  original  simulated  target,  returned  data  items,  subsequent 
analysis  of  the  content  (with  a  description  of  what  was  found),  an  analysis  of  the 
returned  item  with  respect  to  the  target  to  determine  whether  the  item  can  offer 
any  influence  on  decisions  in  the  target  concept  area  The  analysis  was  based 
reviewing  the  context  of  the  data  item  to  determine  any  common  areas  of 
interest  or  duplication  -  specifically  details  regarding  location  or  usage  of  a 
component,  similar  requirements,  common  designs  or  renderings,  or  similar 
functionality, 

Run  /.  Inclusion  of  a  Large  Access  Panel  on  the  Front  of  the  MSV 

Table  5  1  provides  a  summary  of  the  results  of  the  analysis.  In  total, 
fourteen  items  were  returned  from  the  data  advisor  Subsequent  analysis  of 
each  data  item  showed  none  of  the  items  had  relevance  to  the  simulated  target 
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transmission) 

Tank-related  concapt 

No 

M2A2  Iso  Drawing  (laft  front 
vlaw)  A  Plctura 

Drawing  of  tha  M2A2  Sradlay 

IF  V  showing  tha  main 
improvements  over  tha  aartiar 
M2A1  vehicle 

Tank-related  concapt 

No 

M2A3  with  Cl  TV  Photograph 
(front  vlaw)  A  Plctura 

Rale  a  sad 2 005-02  22  10  46  42 
EST 

Photograph  of  tha  United 
Defense  Sradlay  M2A3  with 
Commander's  Independent 
Viewer  mounted  on  tha  right 
raer  (behind  commander's 
hatch)  of  tha  turret. 

Tank-ralatad  concapt 

No 

M2  A3  w/MK44  30 mm  Cannon 
V/ahtcle  Prototypa  Photo  (front 
vlaw)  A  Plctura 

Photograph  of  tha  United 
Defense  LP  prototype 
Installation  of  tha  MK  44  30 
mm  cannon  upgrade  on  a 

M2A3  series  infantry  fighting 
vehicle 

Tank-related  concapt 

No 

Vahicia  Charactarlstlcs  -  1  950s 
and  60s  A  Briefings 
RaportsRataasad  11403 
(Vahlcla  Charaotarlstlcs  -  105 

Characteristic  Shaats  for 
wheeled  and  tracked  vehicles 
of  tha  1  0  60s  and  106Os 

Includes  combat  tactical,  and 
trailers 

An  interesting  documant 
displaying  a  history  of 
vachlcias  davalopad  by 

TACOM  However  specific 
information  related  to  access 
panats  was  not  to  ba  found 

No 

FMTV  (M1075A1) 
Charactarlstlcs  Opposad 

Piston  Opposad  Cyllndar 
Englna  A 

Characteristic  Sheet  for 
FMTVA1  M1078A1  2  5  Ton 
Standard  Cargo  Truck  (LIN 

T 0008 1  NSN  2320-01-447- 
8343) 

No  information  related  to 
angina  compartmant  access 

No 

LK  1  0600  -  P  rot  act  ad  Squad 
Carrlar  w/Front  Power  Plant  A 

Protected  Squad  Carrlar 
w/Front  Power  Plant  (LK10600) 
Concapt  Summary  Concapt 
carries  3  vahicia  craw  and  8 
dismount  troops 

Anti-Aircraft  Qun  Vahlcla 
Photograph  (right  front  view)  A 
Plctura 

Extromely  old  photograph  (pre- 
1 960‘s ).  no  value 

No 

Englnaar  Vahicia  Photograph 
(laft  front  vlaw)  A  Plctura 

Extremely  old  photograph  (pre- 
1960  s)  no  value 

No 

LC126B1  -  DFS  »4  Front 

Armor  Effacts  A 

Design  Feasibility  Study  (DFS) 
04  Front  Armor  Effacts 

Drawing  (LC12661).  datad  May 
1,  1900  This  drawing  shows 
tha  affect  of  three  front  armor 
options  on  tha  overall  vahicia 
configuration 

Armored  fighting  vahicia 
ooncept 

No 

648  Enginaartng  Modal 
Mathodology  Workshop  (Jun 
04)  A  Srlaflngs  Reports 

Engineering  Modal 

Mathodology  Workshop  datad 
July  1 . 2004  This  training 
material  was  presented  to  tha 
FTTS  Government  Working 
Group  July  1 . 2004 

Mathodology  based  activities 

No 

LK  1 0372  XM 1  Tank  with 
Ammunition  Compsrtmsnts  A 

XM  1  Tank  with  Ammunition 
Compartments  (LK  10372) 
Concapt  Summary,  January 
1972 

Armored  fighting  vehicle 
concapt 

No 

LC 12650  -  M2A1  Englna 
Compartmant  Envelope 
DrawIngA 

M2A1  Englna  Compartmant 
Envelope  Drawing  datad 

March  21  .  1990 

Armored  fighting  vehicle 
concapt 

No 

LC  12080  -  DFS  04  Engine 
Compartmant  Dimensions  A 

DFS  94  Engine  Compartmant 
Dimensions  Drawing 
(LC12L60).  datad  April  26 

1990 

Hard  to  relate  to  any  particular 
concapt 

No 

Table  5.1  Results  from  Test  Run  I 
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Run  //:  Separation  ofjhe  Fuel  Tank  into  Two  Container 

Table  5.2  provides  a  summary  of  the  results  of  the  analysis.  In  total,  two 
items  were  returned  from  the  data  advisor  Subsequent  analysis  of  each  data 
item  showed  none  of  the  items  had  relevance  to  the  simulated  target  area. 


Target  Description 

Separation  of  the  fuel  tank  into 
two  containers 

Data  Item  Description 

Analysis  of  Content 

Comparison  Against  Target 

Relevant 

(Yes/No) 

Ml  Fuel  Tanks  (fromTM9- 
2350255-10)  A  General 
Document  Released  9276  (Ml 
Fuel  Tanks  (from  TM  9-2350 
255- 

Locations  and  volumes  of  fuel 
tanks  in  Ml  Page  taken  from 
TM  9-2350255-10 

Tank-related  layout 

No 

Lightweight  JP-8  Fuel  Tank 
Power  Sys  for  UAV,  UGV,  & 
APU  A 

Lightweight  JP-8  Fueled  Power 
Systems  for  UAV,  UGV,  and 
APU  Applications  Report 
dated  July  2002.  This  paper 
was  prepared  for  the  AUVSI 
2002  Unmanned  Systems 
Conference  (July  9-1 1  2002) 

Engine-analysis 

No 

Table  5.2  Results  from  Run  ll 


Run  III:  Improved  Ergonomics  and  Accessibility  to  the  Communications  Module 

through  Relocation  of  Components 

Table  5.3  provides  a  summary  of  the  results  of  the  analysis  In  total,  ten 
items  were  returned  from  the  data  advisor.  Subsequent  analysis  of  each  data 
item  showed  three  items  having  possible  relevance  to  the  simulated  target  area. 
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Target  Description 

improved  ergonomics  end 
eccessebility  to  the 
communications  module 
through  ra location  of 
components 

Data  Itam  Description 

Analysis  of  Content 

Comparison  Against  Target 

Relevant 

(Ves/No) 

A  Briefings 

on  Vulnerability  from  e  C4I  & 

High-level  overview 

No 

FTTS  Updated  with  C4ISR  A 
Analysis 

Weight  Study 

Weight  Study 

No 

FCS  Vetronics  end  C4ISR  Pit 
Stop  Standards  of  Excellence 

A  Bnefings  Reports 

Summery  information  on  en 
FCS-releted  Pit  Stop 

Several  items  related  to  the 
placement  end  wiring  of  C4ISR 
equipment 

Yes 

LC 11 894  -  AFV  C4  IEW 

Vehicle  A 

Armored  Family  of  Vehicles 
(AFV)  C4  Vehicle  (FV-9)  IEW 
Variant  Vehicle  (LC1 1894) 
Concept  Summery,  dated  July 
1987  The  C4  IEW  Vehicle  is 
integrated  onto  the  35  ton 
Medium  Chassis 

Fighting  vehicle- related  layout 

No 

LC11906-  AFV  C4  ETAS 
Vehicle  A 

AttnoredT-amliy  dt  Vehicles 

(AFV)  Assault  Support  (FV-9) 
C4  ETAS  Vehicle  (LC1 1906) 
Concept  Summery;  dated  July 
1987  The  C4  ETAS  Vehicle  Is 

Fighting  vehicle-related  layout 

No 

Feasibility  of  Using  Vehicle  s 
Power  Line  es  CommoBus  A 
Bnefings  Reports 

Feasibility  of  Using  Vehicle's 
Power  Line  es  e 

Communication  Bus  briefing 
dated  June  2004  This  briefing 
was  prepared  by  Weyne  Stete 
University  at  the  4th  Annuel 
Intelligent  Vehicle  Systems 
Symposium.  21-24  June  2004 

Using  power  lines  for 
transmitting  communication- 
based  date  to  the  C4ISR  units 

Yes 

Becoming  en  Expert  et 
Architectures  (Jun  *03)  A 
Briefings  Reports 

Bacoming  and  Expert  at 
Architectures  -  An  Iterative 
Approach  briefing;  dated  June 

1 1 ,  2003  Briefing  presented  et 
the  NDIA  3rd  Annual  Intelligent 
Vehicle  Systems  Symposium 

Process-related  ectivites 

No 

FTTS  Operational  Modeling 
Results  (TACOM  Jul  '03) 
ABriefings  Reports 

Future  Tectical  Truck  System 
(FTTS)  Operational  Modeling 
Results  Briefing;  dated  July  28, 
2003 

Side-by-side  compenson 
between  the  HEMMT  end  the 
FTTS  concept  Simuletions 
end  numbers  provided 

Yes 

Integration  of  Autonomous  Sys 
Comp  Using  JAUS 

Architecture  A 

Integration  of  Autonomous 
System  Components  Using  the 
JAUS  Architecture  Report 
dated  July  2003.  This  paper 
was  prepared  for  the  AUVSI 
2003  Unmanned  Systems 
Conference  (July  15-17  2003) 

Theoretical  overview 

No 

M4Commend  &  Control 

Vehicle  (C2V)  Brochure  A 

United  Defense  brochure 

Fighting  vehicle  descriptions 

No 

Table  5.3  Results  from  Run 
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Figure  5.1  shows  a  snapshot  of  the  data  from  one  of  the  three  items  (a 
study  from  Wayne  State  University  on  using  vehicle  power  lines  as  a 
communication  bus).  Note:  the  data  item  was  classified  as  “Public  Release"  by 
the  Advanced  Concepts  Team. 


Throughput  Analysis 


Throughput  comparison  of  Power  Line 
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Figure  5.1  Portion  of  WSU  Briefing  on  Duai  Power/Communication  Lines 


Run  IV:  Modified.  Location  and  Functionality  of_a  Self_Defense  Weapon 

Table  5  4  provides  a  summary  of  the  results  of  the  analysis  In  total, 
eleven  items  were  returned  from  the  data  advisor  Subsequent  analysis  of  each 
data  item  showed  three  items  having  possible  relevance  to  the  simulated  target 


area. 
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Targat  Da  script!  on 

Location  and  functionality  of  a 
"aelf  defense”  protection 
weapon 

Data  Item  Description 

Analysis  of  Content 

Comparison  Against  Targat 

Relevant 

(Yas/No) 

Evaluation  of  Gunner  Station 
for  Fire-On-The- Move- Phase  II 

Evaluation  of  Gunner  Station 
Configuration  for  Firing-on-the- 
Move  (Phase  II)  report 
prepared  by  US  Army  Human 
Laboratory  dated  January 

1982 

includes  the  effects  of  terrain 
as  well  as  changes  In  reaction 
time  due  to  riders  sitting  log 
periods  within  vehicles 

Yes 

Gun  Propulsion  Emerging 

Army  Technologies  (JPL  88) 

This  report  explores  the 
potential  application  of  Liquid 
Propellents  Advanced  Solids, 
and  Electric  gun  propulsion 
technologies  to  meet  the 
mission 

Primarily  deals  with  Howitzer 
level  gun  propulsion 

No 

M2A3  W/MK44  30mm  Cannon 
Vehicle  Prototype  Photo  (front 
view)  Picture 

Photograph  of  the  United 
Defense  LP  prototype 
installation  of  the  MK  44  30 
mm  cannon  upgrade  on  a 

M2A3  senes  infantry  fighting 
vehicle,  Photograph  is  courtsey 
of  Janes  com 

Tank-related  photograph 

No 

ASM  Other  PMavy  Protection 
Systems  Final  Report  (TCM 

03) 

Other  Heavy  Protection 
Armored  Systems 
Modernization  Systems  - 
System  Concept  and  Design 
Analysis  -  Final  Report  datad 
August  1993 

Requirements  document  for 
armored  fighing  vehicles 

No 

Hit  Avoidance  Regional 
Protection  System  (Apr  03) 

Hit  Avoidance  Regional 
Protection  System 
(HARPS)briefing;  dated  April 
2003 

Overview  presentation  on  e 
TARDEC  technology  program. 

No 

Active  Protection  System 
DROZD  Video 

Active  Protection  System  - 
DROZD  Video  (14  42  minutes) 

A  foreign-made  technical  video 
showing  various  armor  attacks 
and  hits  over  a  period  of  time 

No 

Self-Awareness,  Monitoring, 
Diagnostics  &  Prognostics  A 
Briefings  Reports 

Self-Awareness,  Monitoring 
Diagnostics  &  Prognostics  for 
Intelligent  Vehicle  Syslems 
briefing 

General  overview  of  using 
sensory  data  for  monitoring 
health  of  veheiles 

No 

UGV  Mobility  and  Self- 
Protection  (Apr  03) 

Unmanned  Ground  Vehicle 
(UGV)  Mobility  and  Self- 
Protection  briefing;  dated  April 
29,  2003.  Briefing  presented  o 
the  Army  Science  Board, 
Platform  and  Weapon  Systems 
Panel. 

Three  important  information 
points  applicable  for  the  FTTS 
concept  (1.)  Maneuvarabllrty 
over  rough  terrain,  (2  )  Ground 
clearance  pros  and  cons,  (3  ) 
impact  points  for  ground 
explosive  (e  g  land  mines) 

Yes 

Self-Awareness,  Monitoring  & 
Diagnosis  for  Autonomous 
Vehicle  Operations 

Self-Awareness,  Monitoring  & 
Diagnosis  for  Autonomous 
Vehicle  Operations  Report 

General  overview  of  using 
sansory  data  for  monitoring 
health  of  veheiles 

No 

Small  UAV  Weapon  izat  ion 
(AUVS  l Flnal) 

Use  of  Alternative  woaptons 

Aerial  weapons 

No 

Weapon  Systems  Handbook 
2005  (narratives) 

Description,  specifications, 
program  status,  and  projected 
activities  for  currently  fielded 
weapon  systems.  Handbooks 
from  previous  yeer  can  be 
found  as  attachments 

Very  good  ovarview  of 
technology  capabilities  within 
the  Army 

Yes 

Table  5.4  Results  from  Run  IV 
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Run  V ;  Recommendation  on  External  Storage  of  Ammunition 

Table  5,5  provides  a  summary  of  the  results  of  the  analysis.  In  total,  two 
items  were  returned  from  the  data  advisor  Subsequent  analysis  of  each  data 
item  showed  one  item  having  possible  relevance  to  the  simulated  target  area. 


Target  Description 

External  Storage  of 

Ammunition 

Data  Item  Description 

Analysis  of  Contant 

Comparison  Against  Target 

Ralavant 

(Yas/No) 

Stretched  M113A1  Ammunition 
Storage 

Ammunition  Stowage  in 
Stretched  M113A1  using 
Ammunition  Containers 

Concept  Summary  dated 
August  7,  1978 

This  document  was  produced 
in  1978  for  the  M133A1 
vehicle.  What  is  Interasting  is 
the  information  and  datalls  as 
to  how  large-caliber  shells  are 
stacked  and  arrangad  for 
storage  within  tha  vehicle. 
Considerations  for  weight 
(ability  to  load  and  unload) 

Yes 

Explosive  Reactive  Armor 
Sketch 

Simple  sketch  of  tha  affect  of 
armor  against  axploslva  - 
layars  of  external  armor 
affected 

Sketch  was  too  simpla  for 
understanding  relatad  mora  to 
external  armor 

No 

Table  5.5  Results  from  Run  V 


Run  VI:  Powertrain  Exhaust  Routing  from  the  Rear  of  the  MS  V. 

Table  5.6  provides  a  summary  of  the  results  of  the  analysis  In  total, 
three  items  were  returned  from  the  data  advisor.  Subsequent  analysis  of  each 
data  item  showed  none  of  the  items  had  relevance  to  the  simulated  target  area. 
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Target  Description 

Powertrain  exhaust  routing  out 
of  the  back  of  the  MSV 

Data  Item  Description 

Analysis  of  Content 

Comparison  Against  Target 

Relevant 

(Yes/No) 

On-Board  Vehicle  Power 
Briefings  Reports 

Briefing  presented  at  the  Joing 
Service  Power  Expo,  May  2005 

General  overview  of  the  stete 
of  powertrain  vehicles  in  the 
militery 

No 

Power  Assessment  & 
Distribution  Briefings  Reports 

Power  Assessment  & 
Distribution  briefing  deted  May 
2-5,  2005.  This  briefing  was 
presented  et  the  Joint  Services 
Power  Expo  on  May  2-5,  2005. 

Designing  power  systems  for 
distribution  ecross  the  vehicle 

No 

Single  Regime  Power  Split 
Trensmlsslon  for  Militery 
Vehicles 

Single  Regime  Power  Split 
Transmission  for  Heevy  Duty 
Miiitery  Vehicles  peper,  dated 
June  2005.  This  paper  wes 
prepared  for  the  6th 
Intemetionel  Ali  Electric 

Combet  Velcle  Conference  13- 
16  June  2005 

Related  to  power  issues  faced 
by  hybrid  end  fuel  cell  vehicles 

No 

Table  5.6  Results  from  Run  VI 


Analysis  of  Case  Study  I 

The  results  of  the  six  runs  provided  an  accurate  portrayal  of  the  makeup 
of  the  ACT  data  subset  since  the  results  included  a  variety  data  items  - 
photographs,  videos,  drawings,  concept  documents,  presentations,  and  external 
reference  material.  A  snapshot  of  the  overall  results  from  the  six  runs  is 


provided  in  Table  5.7. 
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Run 

Number 

Target  Description 

Number  of 

Returned 

Results 

Number  of 

Relevant 

Items 

Percentage 
of  Hits 

1 

Inclusion  of  a  large  access  panel  on  the  front  of  the  MSV 
to  allow  easier  access  to  the  engine  compartment. 

14 

0 

0.0% 

II 

Separation  of  the  fuel  tank  into  two  containers 

2 

'  0  1 

0  0% 

III 

Improved  ergonomics  and  accessability  to  the 
communications  (C4I)  module  through  relocation  of  the 
components 

10 

3 

30.0% 

IV 

Location  and  functionality  of  a  "self  defense"  protection 
weapon  (gun  or  other) 

11 

3 

27.2% 

V 

External  Storage  of  Ammunition 

2 

1 

50.0% 

VI 

Powertrain  exhaust  routing  out  of  the  back  of  the  MSV 

3 

0 

0  0% 

Total 

42 

— im — 

Table  5.7  Summary  of  Runs  for  Case  Study  I 


From  the  analysis,  three  of  the  runs  yielded  results  having  no  relevancy  to 
the  target  area  in  question  Besides  an  obvious  consideration  of  the  ACT  data 
subset  possibly  not  having  enough  data  to  support  the  three  simulation  runs, 
another  possible  reason  why  no  data  was  found  is  due  to  the  nature  of  the 
modified  target.  It  is  likely  the  modification  recommendation  originated  from  a 
functional  or  “downstream”  reviewer  with  substantial  knowledge  of  field-related 
domain  expertise  not  typically  found  with  the  concepting  team 

In  contrast,  three  runs  did  yield  data  items  that,  on  initial  analysis,  had 
enough  similarities  to  the  simulated  targets  to  warrant  consideration.  In  further 
support  of  the  previous  hypothesis  where  “domain  expertise”  is  a  factor,  the 
three  runs  were  all  related  to  general  functionality  and  subsystem  location- 
common  themes  in  envelope  design  during  concept  development.  Therefore,  it 
is  feasible  to  assume  these  general  topics  have  been  covered  during  prior 
concepts  development  activities  and  data  elements  representing  outcomes  are 
part  of  the  ACT  body  of  knowledge 
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Of  all  returned  data  items  showing  relevance  in  the  test  runs,  the  item  of 
most  interest  is  likely  from  Run  V  (External  Storage  of  Ammunition).  The  data 
item  was  from  a  study  conducted  in  1978  on  an  armored  fighting  vehicle 
(M113A1).  While  the  vehicle  itself  has  little  correlation  with  the  FTTS-MSV,  it  is 
the  analysis  of  how  ammunition  should  be  stacked  and  arranged  for  firing, 
including  container  sizes  of  the  ammunition  and  the  process  for  inserting  and 
removing  ammunition  cartridges  that  may  be  of  significant  interest  to  a  concept 
decision  maker. 

Analysis  of  Case  Study  I  with  the  Advanced  Concepts  Team 

The  results  of  the  simulation  runs  were  reviewed  with  members  of  the 
Advanced  Concepts  Team  (ACT)  for  further  analysis  and  comment.  The 
hypothesis  supporting  domain  expertise  playing  a  role  in  the  identification  for 
modified  items  was  supported  by  the  (ACT).  Further,  the  data  item  from  Run  V 
described  above  (1978  M113A1  ammunition  analysis)  generated  the  most 
individual  discussion,  since  the  team  agreed  it  may  have  some  interesting  data 
points.  The  team  also  confirmed  the  item  had  not  been  considered  in 
development  of  the  MSV  concept  due  to  the  age  of  the  study. 
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CASE  STUDY  II  CONCEPT  DECISION 

The  second  case  study  with  the  FTTS  MSV  concept  involved  the 
development  of  a  multi-purpose  crane  consolidating  several  material  handling 
operations.  For  this  case  study,  a  concept-level  decision  was  simulated  which 
encompassed  the  use  of  several  key  framework  and  prototype  features.  In  the 
role  of  a  decision  maker,  a  decision  task  was  be  assigned  to  review  the  multi¬ 
purpose  crane  concept  and  determine  whether  proper  considerations  have  been 
made  prior  to  moving  forward  into  further  design  work  To  complete  the 
simulated  decision,  three  areas  related  to  the  decision  activity  were  addressed. 

•  Interpretation  of  key  requirements  forming  the  “background”  of  the 
decision. 

•  Review  and  identification  of  relevant  data  obtained  through 
decision  advising  applications. 

•  Creation  of  a  decision  object  linking  need,  decision,  and  result. 

Key  Requirements  Background 

The  list  of  requirements  for  the  FTTS  MSV,  many  of  which  also  impact  the 
multi-purpose  crane,  was  extensive  A  detailed  list  of  requirements  can  be  found 
in  the  FTTS-MSV  Emerging  Desired  Capabilities  document  [134].  The  partial  list 
below  provides  some  insight  to  the  types  of  requirements  supported  by  the 
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material  handling  system  in  the  concept.  Many  of  the  requirements  listed  were 
also  used  to  create  the  "needs"  linkages  on  to  the  decision  object  accompanying 
completion  of  the  workflow  activity. 

•  Allow  the  MSV  vehicle  to  physically  back  up  into  a  target  transport 
airplane  (e.g.  C-130),  remove  cargo  material  directly  off  the  plane, 
and  provide  capabilities  similar  to  forklift  to  move  and  arrange 
cargo  as  necessary.  [134] 

•  Allow  cargo  to  be  loaded  and  arranged  either  on  to  it  or  to  other 
cargo  vehicles  [134] 

•  Facilitate  several  pre-programmed  motion  sequences  to  allow  the 
crane  to  be  quickly  extended  to  certain  distances  without  having  an 
operator  control  every  element  of  the  sequence.  [134] 

•  Support  a  "variable  height"  suspension  to  allow  the  chassis  to 
adjust  to  the  level  needed  to  manipulate  the  cargo.  [134] 

•  Support  SMART  initiatives  for  reducing  material  handling  systems 
throughout  the  Army  [127]. 

•  Improved  load  and  unload  time  [134] 

•  Reduced  need  for  additional  equipment  [134] 

•  Reduced  maintenance  times  and  costs  [134] 

•  Reduced  number  of  personnel  necessary  for  material  handling 
[134] 

•  Support  load  and  unload  operations  in  rough  terrain  [134] 
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•  Support  landings  in  "hot  spots"  e.g.  active  military  theaters  [1 34] 

•  Support  for  cargo  payload  capacity  of  1 1  tons.  [134] 

•  Maximum  load  capacity  (cargo  and  vehicle)  of  13  tons  [134]. 

Review  and  Identification  of  Relevant  Data 

With  requirements  in  hand  the  CSCW  prototype  was  leveraged  to 
determine  if  there  are  items  within  the  existing  data  set  which  may  possibly 
influence  the  opinion  of  the  decision  maker.  With  reference  to  Tversky’s 
concepts  of  bias  [102],  it  was  considered  important  to  identify  relevant 
information  within  a  small  number  of  initial  reference  points  Prototype 
information  was  harnessed  from  the  following  sources: 

•  Data  elements  from  the  CSCW  prototype  based  on  metadata  and 
content  extracted  from  the  Advanced  Concepts  Team's  data  set. 

•  Decision  and  risk  data  elements  simulated  within  the  CSCW 
prototype  environment 

Ultimately,  the  simulations  ran  in  the  prototype  were  intended  to  answer 
the  following  questions' 

1  Does  any  background  information  exist  related  to  either  for  the 
FTTS  program  or  any  other  system  serve  as  a  precedent  for  the 
multi-purpose  crane  concept9 
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2.  Can  any  past  decisions  offer  guidance? 

3.  Are  there  aspects  of  the  concept  should  merit  cause  for  concern? 

The  first  simulation  was  intended  to  locate  data  items  having  relevance  to 
the  decision  on  the  multi-purpose  crane.  Using  a  limited  amount  of  key  concepts 
(PLS,  pallet,  crane,  cargo),  a  set  of  data  was  filtered  from  the  prototype  analysis 
tool.  Table  5.8  provides  a  summary  of  the  results  of  the  analysis  of  locating 
relevant  data  items.  In  total,  thirteen  items  were  returned  from  the  data  advisor. 
An  analysis  of  the  data  determined  five  of  the  items  had  relevance  to  the  multi¬ 
purpose  crane  decision  activity. 
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Tsrget  Description  - 
Reftreno*  Data 

Multi-Purpose  Crane  for  the 
FTTS-MSV 

Data  Item  Description 

Anstysls  of  Content 

Comps ris on  Agslnst  Tsrget 

Relevs  nt 
(Yes/No) 

LK10998  -  Weight  Comparison 
LK10998  v  M1E1  A  MAS  Dote 

Weight  comparisons  (ovarell 
and  broken  down  by  functional 
areas)  Advanced  Concepts 

Comparison  of  Tank  Systems 

No 

Smart  Distribution  (3Doc02) 
Briefings  Reports 

Smart  Distribution  A  System 
of  Systems  for  the  Objective 
Force  briefing;  dated 

December  3.  2002  This 
braiflng  was  prasantedat  tha 
FTTS  Industry  Day  (3Dec02). 

Describes  the  objectives  of 
SMART  In  relation  to  material 
handling.  Entire  presentation 
is  reinvent  to  tha  mullt-purpose 
crane 

Yas 

Dynamic  Analysis  of  PLS 

Computer-Based  Dynamic 
Performance  Analysis  of  tha 
Palletized  Load  System  (PLS) 
Transporting  PLS  Concept 
Variants 

Extremely  technical  paper 
describing  the  effects  on  the 
pallatized  load  system. 
Technical  data  relevant  from 
load  vs  center  of  gravity  and 
other  studies 

Yes 

Ml 076  PLS  T roller  Photograph 
(left  front  view)  A  Picture 

Ml 078  PLS  Trailer  Photograph 
(left  front  view)  Please  note 
that  this  photograph  (minus 
background)  is  also  attached 
as  secondary  content  at  the 
bottom  of  this  page 

Picture  of  trailer  No 
information  related  to  cranes 

No 

PLS  Container  Handling  Unit 
Specifications  A  Picture 

Palletized  Load  System  (PLS) 
Truck  and  Container  Handling 
Unit  Brochures  and  Pictures, 
dated  2000. 

Shows  the  "Hook  and  Lift" 
features  of  tha  HEMMT 

Yas 

PLS  Engineer  Variants 
Requirements  &  Concepts 
Report  (’96) 

Palletized  Load  System  (PLS) 
Alternative  Engineer  Uses 
Requirements  Definition  and 
Concepts  Report;  dated 
December  1996. 

Prioritized  load  system 
requirements,  including  a  QFD 
analysis 

Yas 

PLS  Alt  Engr  Uses  - 
Requirements,  Concepts,  & 
Schedule 

Palletized  Load  System  (PLS) 
Alternative  Engineer  Uses  - 
Requirements  Definition, 
Concepts,  and  Alalysls 
Schedule 

Timellne-based  chart 

No 

ATLAS  Photograph  (loft  front 
view  w/ pallet)  A  Picture 

All  Terrain  Lifter  Army  System 
(ATLAS)  Photograph  (left  front 
view  w/ pal  let). 

Front  loaded  pallet  mover.  Not 
required  as  part  of  the  MSV. 

No 

M915  -  Palletized  Loading 
System  Domostrotor  (Jun  ’03) 

M915  -  Palletized  Loading 
System  Demonstrator  briefing, 
dated  Juno  11,  2003  Briefing 
presented  by  at  the  NDIA  3rd 
Annual  Intelligent  Vehicle 
Systems  Symposium 

Various  technologies  related  to 
a  trailer 

No 

Pallatized  Load  Systom  (PLS) 
Specifications  Brochure 

Palletized  Load  System  (PLS) 
Specif Icetions  Brochure 

Strongly  focused  on  tha  overall 
vehicle  rather  than  the  crana. 

No 

Pallatized  Load  System  Video 

Pallatized  Load  System  Video 
(13  44  minutes),  dated  about 
1996 

A  lengthy  video  showing  the 
complete  loading  and  removal 
of  pallets  on  the  HEMMT  using 
the  "hook  and  pull”  method. 

An  excellent  primer  on  existing 
technology. 

Yes 

M809/M81  3  Cargo  Truck 

3  view  drawing  of  tha  M809 
chassis  and  characteristic 
sheets  for  tha  M813  Cargo 
Truck 

Dated  aarias  of  drawings 
related  to  traditional  trucks 

No 

FTTS  MS  5.5/1 1  Ton  Corgo 
Truck  Characteristics 

Future  Tactical  Truck  Systems 
(FTTS)  Maneuver  Sustainment 
5  5/11  Ton  Cargo  Truck 

Concept  Characteristics 

Sheets. 

Early  representation  of  tha 
FTTS  MSV  without  tha  multi¬ 
purpose  crane  concept 

No 

Table  5.8.  Relevant  Data  Items  for  the  Multi-Purpose  Crane 
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The  five  relevant  data  items  were  found  to  contribute  in  areas  of  material 
handling  problems  with  existing  equipment  or  validation  of  FTTS-MSV 
requirements  An  example  of  content  cited  as  possibly  relevant  was  provided  in 
Figure  5.2,  an  extracted  from  an  overview  of  SMART  distribution  requirements 
(Source  -US  Army  TACOM  Public  Release). 


Figure  5.2  SMART  Distribution  Requirements 


The  second  simulation  was  directed  toward  finding  past  decisions  meriting 
consideration  with  regard  to  the  crane-related  concept  decision.  As  mentioned  in 
Chapter  4,  the  Advanced  Concepts  Team  (ACT)  has  not  explicitly  practiced 
capturing  decision-related  information  in  a  manner  consistent  with  this 
framework.  Upon  analysis  of  then  ACT  data  subset,  items  appearing  to  be  better 
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suited  toward  an  "outcome"  were  subsequently  created  within  the  prototype  as  a 
"decision"  object 

Table  5.9  provides  a  summary  of  the  results  of  the  simulation  for  locating 
decision-related  items  In  total,  four  items  were  returned  from  the  decision 
advisor.  An  analysis  of  the  data  determined  one  of  the  items  had  relevance  to 
the  multi-purpose  crane  decision  activity.  The  relevant  data  item  was  a  summary 
related  to  early  modeling  and  simulation  activities  on  the  FTTS  concept, 
including  information  specific  to  the  material  handling  functionality. 


Targat  Description  -  Daclslon 

Data 

Multi-Purpose  Crane  for  tha 
FTTS-MSV 

Decision  Item  Dascrlptlon 

Analysis  of  Decision 

Comparison  Against  Target 

Ralevant 

(Yes/No) 

Lesson  from  Past  for  Safer 
Future  Tactical  Veh  (Jun’03)  A 
Briefings  Reports 

A  Las  son  from  the  Past  for 
Safer  Future  Tactcal  Vehicle 
briefing,  datad  Juna  11,  2003 
NDIA  3rd  Annual  Intalligent 
Vehicle  Systems  Symposium 

General  call  for  mora  safety 
with  number  on  accidents 

No 

FCCVS  (Ph  1)  Vol  VIII  Final 
Report  (TCM  '82)  A 

Future  Cloase  Combat  Vehicle 
System  (FCCVS)  Volume  VIII 
Final  report  datad  May  1982 

Detailed  study  on  the 
effectiveness  of  short-ranga 
combat  vehicles.  No 
references  to  load  handling 

No 

FTTS  M&S  Whita  Paper 
(TARDEC  ’03)  A 

Future  Tactical  truck  Systems 
(FTTS)  Modeling  and 

Simulation  Wfriita  Paper,  dated 
July  11,  2003  This  paper 
details  tha  Futura  Tactical 

Truck  Systems  Modeling  and 
Simulation  (M&S)  activitias 

The  paper  axplains  what  has 
been  modeled  and  how  it  has 
been  use 

Dascription  of  tha  results  of 
initial  modeling  and  simulation 
for  the  FTTS.  Includas 
information  on  simulations 
conducted  with  the  material 
handling  system. 

Yas 

FCCVS  (Phil)  Vol  III  Final 
Report  (TCM  ’83)  A 

Future  Close  Combat  Vehicle 
System  (FCCVS)  Phasa  II 
Volume  Ilf  Final  Report;  dated 
August  1983. 

Detailed  study  on  the 
affectivaness  of  short-range 
combat  vehicles  No 
rafarences  to  load  handling. 

No 

Table  5.9  Relevant  Decision  Items  for  the  Multi-Purpose  Crane 
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In  the  final  simulation,  problem  or  issue-related  data  that  forms  the  basis 
of  risk-related  information  was  filtered  with  Table  5.10  summarizing  of  the  results 
of  the  simulation  In  total,  three  items  were  returned  from  the  decision  advisor. 
An  analysis  of  the  data  determined  one  of  the  items  had  relevance  to  the  multi¬ 
purpose  crane  decision  activity.  The  relevant  data  item  was  a  journal  article 
published  in  September  2006  from  National  Defense  [135]  describing  a  hybrid 
power  platform  used  for  the  load  handling  system  suspension  adjustment  on  the 
HEMTT  class  of  vehicles.  According  to  the  article,  a  conventional  truck  has 
some  large  drive-train  components  down  the  middle  of  the  truck  which  impact 
the  location  of  lift  handling  system.  By  going  with  the  hybrid  approach,  the 
design  team  was  able  to  embed  the  load  handling  system  in  a  manner  which 
would  allow  the  lift  systems  to  be  fit  within  the  profile  of  a  transport  aircraft  (e  g. 
C-130  class). 
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Target  Description  -  Risk 

Data 

Mufti-Purpose  Crene  for  the 
FTTS-MSV 

Risk  Item  Description 

Analysis  of  Risk 

Comparison  Against  Target 

Relevant 

(Yes/No) 

Netionel  Defense  Article  (2006) 
-  Technology  Limitations  Stall 
Military  Hybrids 

Cautionary  tale  regerding 

Hybrid  Vehicles  -  continuing  to 
proof  out  hybrid  power 
technologies  Also  Includes 
some  erees  where  hybrids 
heve  shown  success 

Very  Interesting  erticle.  Near 
the  end,  there  is  discussion  on 
how  the  hybrid  has  hed  the 
greatest  success  for  variable 
height  suspensions  (to  relse 
besed  on  the  height  of  the 

Cl 30.)  where  convent lonel 
trucks  heve  problems.  This 
directly  impacts  the  des 

Yes 

Stryker  -  Reports  Cite 

Problems  with  Vehicle  (2005) 

Severel  risks  cited  with  the 
Strkyer  vehicle  -  some  trivel  to 
potentially  major  concerns 

Nothing  related  to  material 
handling  equipment  (not 
applicable  to  the  Stryker) 

No 

RAND  -  Problems  In  Army 
Vehicle  Maintenence 

A  RAND  report  from  1981  on 
problems  related  to  the 
maintenance  of  Army  vehicles 
Problems  Include  manpower, 
training,  equipment  design, 
and  management 

Lessons  may  still  be  valid  for 
training  end  meintenence,  but 
nothing  related  to  material 
handling  systems 

No 

Table  5.10  Relevant  Risk  Items  for  the  Multi-Purpose  Crane 
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Creation  of  the  Decision  Object  for  the  Activity 

Using  the  simulation  results  returned  from  the  decision  advisor, 
information  was  saved  to  a  decision-oriented  object  to  denote  key  charactenstics 
of  the  decision.  Table  5  11  summarizes  elements  of  metadata  captured  on  the 
decision  object 


Attribute  Name 

Value 

Name 

Decision  -  FTTS  Multi-Purpose  Crane 

Title 

Multi-Purpose  Crane  Information  Analysis 

Description 

Review  of  information  supporting  the  FTTS 
MSV  Multi-Purpose  Crane 

Cost  Considerations 

None 

Timing  Considerations 

None 

Deliverable  Considerations 

Please  refer  to  the  attached  issue  in  relation  to 
the  support  for  variable  load  platforms  in  the 
HEMTT's  conventional  power  systems 

Please  make  sure  this  is  no  an  issue  for  the 
FTTS-MSV  in  its  demonstrator  vehicles 

End  State  of  Concept 

FALSE 

Issue  Related 

TRUE 

Major  Decision  Related 

FALSE 

Milestone  Related 

FALSE 

Requirement  Related 

TRUE 

Resource  Related 

FALSE 

Timeframe  Related 

FALSE 

Table  5.11  Summary  of  Decision  Object  Characteristics 


A  view  of  the  persisted  decision  object  from  the  CSCW  prototype  is  shown 


in  Figure  5  3 
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Figure  5.3  Completed  Decision  Item  within  the  CSCW  Environment 
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Analysis  of  Case  Study  II 

The  second  case  study  successfully  touched  all  four  elements  of  the 
framework  -  utilizing  a  CSCW  environment  for  managing  information,  work 
conducted  within  a  product  development  process  work  stream,  leveraging 
decision-oriented  information,  and  making  use  of  risk  information  Prototype 
advisor  tools  were  used  to  locate  information  having  significance  to  the  simulated 
decision,  and  relevant  information  was  captured  in  a  decision-based  object. 

The  information  returned  from  the  first  simulation  runs  -  similar  to  items 
returned  in  the  first  case  study  -  suggest  inputs  to  a  decision  maker  who, 
depending  on  their  experience  with  the  concept,  may  find  relevant  By  far,  the 
most  interesting  aspect  of  the  information  returned  had  to  do  with  the  single  risk 
item  related  to  an  article  from  the  publication  National  Defense  on  the  apparent 
problems  with  the  Army's  Hybrid  vehicles  [135].  While  the  tone  of  the  article  is 
cautionary  in  regard  to  hybrid  vehicle  technologies,  it  is  near  the  end  of  the 
article  where  some  information  appeared  to  be  “different"  to  what  has  been 
previously  identified  or  discovered  According  to  the  article  -  which  includes 
comments  from  TACOM-based  engineers  not  linked  to  the  Advanced  Concepts 
Team  -  hybrids  where  the  only  platform  to  fully  support  a  strategy  to  get  load 
handling  systems  to  the  same  elevation  as  the  C-130  cargo  hold  for  the  HEMTT 
vehicles.  According  to  the  article,  a  conventional  truck  has  some  significant 
drivetrain  components  in  the  center  of  the  truck  affecting  on  the  location  of  lift 


122 


equipment  By  going  with  the  hybrid  approach,  the  design  team  was  able  to 
embed  the  load  handling  system  within  the  profile  of  the  C-130  airplane. 

In  the  role  of  the  decision  maker,  the  information  from  the  simulation  may 
be  considered  quite  significant  to  the  concept  since  the  HEMTT  -  the  most 
recent  “precursor”  to  the  FTTS  system  -  was  described  to  have  problems  with 
variable  elevation  operations  of  the  cargo  deck  with  conventional  drive  trains  As 
a  decision  maker,  a  next  step  would  be  to  make  sure  the  information  is  further 
investigated  and  reviewed  within  the  concept  development  activities  Feedback 
from  the  investigation  and  review  should  be  incorporated  into  the  development  of 
the  FTTS-MSV  and  future  concept  work. 

Analysis  of  Case  Study  H  with  the  Advanced  Concepts  Team 

The  results  of  the  there  simulation  runs  were  reviewed  with  members  of 
the  Advanced  Concepts  Team  (ACT)  for  further  analysis  and  comment.  The 
team  expressed  interest  in  the  three  sets  of  information  presented  by  the 
advisor.  The  journal  article  on  hybrid  technology  generated  the  most  discussion, 
as  it  was  deemed  an  important  reference  point.  The  lead  concept  engineer  on 
the  multi-purpose  crane  mentioned  he  was  aware  of  the  design  issues  with 
adjustable  suspensions  on  the  HEMTT,  so  it  is  plausible  the  issue  was 
considered  during  the  concept  phase. 
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OVERALL  ANALYSIS 

From  an  overall  perspective,  the  CSCW  prototype  developed  with  the 
principles  of  the  framework  performed  well  with  the  two  test  cases.  As 
demonstrated  in  Case  Study  II,  all  elements  of  the  framework  were  leveraged  in 
the  decision  making  exercise.  In  support  of  Tversky  et.  al  [102]  as  well  as 
Linden’s  design  of  Amazon.com  recommendation  lists  [90],  the  filtered  data  sets 
returned  to  the  decision  maker  from  the  advisor  tools  was  limited  to  a  select 
group  of  results.  The  feedback  from  the  Advanced  Concepts  Team  on  the 
framework  was  also  positive.  Along  with  the  analysis  provided  on  during  the 
review  of  the  two  case  studies,  the  team  viewed  the  framework  as  a  possible 
avenue  for  planning  and  deployment  for  future  collaborative  systems 

In  terms  of  the  data  discovery,  both  case  studies  demonstrated  the  affect, 
as  described  by  O’Dell  et.  al  as  "if  we  only  knew  what  we  know”  [13]  In  Case 
Study  I,  a  legacy  ammunition  study  offered  insight  related  to  packaging,  storage, 
and  removal  of  munitions  magazines.  In  Case  Study  II,  lessons  learned  from  the 
application  of  a  variable  height  material  handling  deck  on  a  precursor  to  the 
FTTS-MSV  could  have  impact  on  the  multi-purpose  crane  concept.  In  both 
situations,  the  information  was  not  explicitly  called  out  as  “FTTS  related”  or,  in 
the  case  of  the  multi-purpose  crane,  as  "material  handling  equipment"  related. 
Still,  the  prototype  successfully  put  forward  "discovered"  information  which 
potentially  had  a  level  of  significance  on  the  overall  concept  decision  activity. 
The  two  discoveries  provide  validation  for  the  framework  by  leveraging 


information  for  leaders  make  better  decisions 
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CHAPTER  6  -  CONCLUSION 

SUMMARY 

Bringing  new  products  to  market  is  a  relentless  task  due  never-ending 
competitive  and  technological  pressures.  Even  with  advances  put  forth  through 
formalized  product  development  processes,  computerized  tools,  and  other 
technologies,  the  process  of  bringing  a  product  from  concept  to  product  has  not 
become  any  less  complex.  Throughout  all  product  development  activities, 
decision  making  remains  a  cornerstone  activity  affecting  every  aspect  of  the 
process.  The  challenge  of  any  product  development  organization  is  to  ensure 
consistent,  timely,  and  complete  information  is  provided  to  decision  makers  to 
facilitate  faster  and  more  accurate  decision  making 

The  premise  of  this  research  was  to  investigate  what  can  be  done  to 
optimize  development-focused  computer  tools  to  allow  improvement  through 
reducing  levels  of  uncertainty  in  concept  development  decision-making  The 
result  of  the  research  was  a  four-element  framework  offering  guidance  for  both 
implementation  and  usage  of  managed  data  for  concept  development  activities 
The  framework  itself  offers  no  “quick  fixes”  -  no  panaceas  for 
organizations  struggling  with  systems  deployed  to  support  product  development 
activities  Further,  the  framework  does  not  advocate  any  “miracle"  technology  to 
take  the  place  of  the  decision  maker.  Rather,  through  the  application  and  use  of 
the  framework  principles,  organizations  can  begin  to  move  beyond  using 
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collaborative  data  management  systems  to  supplement  processes  Instead, 
organizations  can  harness  the  power  of  their  information  to  “move  the  bar"  in 
reducing  uncertainty  and  positively  impact  the  concept  development  process. 
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CONTRIBUTIONS 

identification  of_  a  senes  qf_  steps  covering  both  implementation  and_  usage  for 

optimizing  CSCW  system  benefits  for  decision  makers. 

The  four  core  elements  of  the  framework  provide  a  guide  covering  both 
implementation  (“pre-production”)  and  usage  (“production”).  Additionally,  the 
elements  provided  in  the  framework  are  constructed  for  directed,  practical 
application. 

jntroductigri  of_  the  “Need-Decision-Result"  (NDR)  relationship  for  extracting, 

storing  and  reusing  decisiorhrelated_  data 

Within  this  framework,  decision  information  has  been  shown  to  be  a 
valuable  commodity  for  gleaning  useful  insight  to  aid  concept  product 
development  decision  making.  The  framework  advocates  capturing  key 
elements  of  a  decision  having  relevance  to  future  decision  makers  combined 
with  information  supporting  both  “before”  (the  needs)  and  “after”  (the  results) 
aspects  of  the  decision 
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FURTHER  WORK 

The  introduction  of  the  framework  allows  a  number  of  opportunities  for 
future  work  Because  the  value  of  harnessing  decisions  needs  to  occur  over  a 
relatively  long  period  of  time,  a  long-term  study  should  be  commissioned  to 
examine  the  effectiveness  of  leveraging  the  NDR  relationship  in  a  concept 
development  environment  A  series  of  checkpoints  and  measurements  should 
be  established  to  measure  how  the  data  set  influences  concept  development 
team  and  decision  makers  over  time.  Monplaisir  [28]  demonstrated  the  use  of 
ANOVA  to  measure  several  key  indicators  within  work  task  processing  to 
determine  whether  CSCW  tools  have  a  statistically  significant  impact  on  product 
development  activities 

The  decision  advisor  tools  used  in  the  CSCW  prototype  should  be 
enhanced  for  production  use.  The  tools  should  be  linked  with  taxonomy  and 
ontologically-based  processing  engines  to  further  improve  the  quality  of  filtered 
data  items.  Further,  it  is  expected  that  advancements  brought  forth  through  the 
Semantic  Web  initiative  may  allow  greater  enhancement  on  both  the  decision 
advising  tools  as  well  as  how  metadata  is  captured  and  managed  within  CSCW 


environments. 
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APPENDIX  A  -  RESEARCH  QUESTIONAIRE 


Purpose 

The  survey  was  to  gain  further  insight  in  the  following  areas- 

•  Identify  types  of  decisions  that  real  organizations  make  in  the  concept  and 
design  phases  of  product  development. 

•  Understand  the  decision  that  is  being  made 

•  The  alternatives/choices  offered  in  the  decision 

•  Who  the  decision-maker(s)  are 

•  What  data  is  directly  impacted  by  the  decision 

•  What  other  data  was  used/referenced  to  make  the  decision  by  the 
decision-maker 

•  How  often  the  decision  is  made  (in  general)  and  estimates  on  which 
alternative  was  chosen. 

•  Reasons  why  the  decision  was  made  in  one  way  or  the  other, 

•  Understand  what  information  systems  are  accessed/referenced  by 
decision  makers  in  order  to  help  them  make  a  decision. 


Approach 

Respondents  involved  with  product  development  participated  in  the  survey  via 
written  correspondence,  live  interview,  or  both  In  the  section  below,  questions 
are  provided  along  with  a  consolidated  set  of  responses  General  responses 
and  the  number  of  observations  are  provided  in  parenthesis. 


Product  Development 

Please  describe  the  major  purposes,  products,  or  functions  of  your  organization 
OEM  automobile  producer  (4) 

OEM  automobile  supplier  (3) 

Government  or  related  -  direct  or  contractor  (6) 

Software  (1) 

Other  (1) 

What  is  your  (or  your  team’s)  role  in  relation  to  product  development  cycle(s)? 
Manager  (6) 

Engineer/Designer  (5) 

Consultant  (3) 

Other  ( 1) 
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In  what  ways  does  your  team  play  a  role  in  some  other  organization’s  (internal  or 
external)  product  development  cycle 
Interne!  (14) 

Extemel  -  Suppher/Contrector  to  another  orgenizetion  (12) 

Extemel  -  Receiver/Contract  Owner  for  other  organizations  (12) 

No  Response  (1) 

To  what  degree  does  your  organization  share  product  development  data 
internally  (with  other  groups)  and  externally? 

Shere  internally  (14) 

Share  externally  (12) 

No  Response  (1) 

Please  describe  key  elements  of  the  IT  structure  used  by  your  or  to  support 
product  development  activities 
" Shared  network  drives" 

CAD " 

"PDM  systems" 

What  does  the  term  “product  development  process”  mean  to  you/your 
organization? 

Design,  engineering ,  velidetion  to  arrive  at  an  end  result  -  customer  satisfying  product' 
Development  of  a  product" 

Does  your  organization  follow  a  standard  or  documented  product  development 
process  (Y/N)? 

Yes  (9) 

No  (4) 

No  response  (2) 

If  yes,  please  answer  the  following  questions: 

Was  your  PDP  developed  internally  (Y/N)? 

Yes  (5) 

Do  not  know  (4) 

Was  your  PDP  based  on  or  influenced  by  any  external  source  -  published 
methodology,  outside  consultant,  related  organization  (Y/N)?  If  yes,  can  you 
name  the  source? 

No  responses  or  "No"  for  ell 

What  are  the  phases  of  your  organization  PDP,  in  particular  the  “early"  phases? 
Define,  establish  procedures,  train,  implement,  refine" 

" Design ,  review,  prototype ” 

Design  prototype ,  testing" 

Overall,  how  "effective"  has  your  PDP  been  in  supporting  the  goals  of  the 
organization? 

Very  effective 
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Somewhat  effective  (4) 

No  reel  effect  on  the  development  ectivities  (neutrel)  (5) 
Some  whet  ineffective  (3) 

Very  ineffective 
No  response  (3) 


Computer  Systems 

Does  your  organization  use  software  systems  to  support  PDP  and  PDP  decision- 
making  activities? 

Yes  (14) 

No  response  (1) 

If  Yes  - 

Please  describe  the  types  of  software  systems: 

CAD-CATIA,  IDEAS,  Pro/E,  AutoCAD,  Unigraphics ,  CADKEY 
PDM  -  Windchill,  Teemcenter 
Access,  Excel 
" Pretty  low  level  stufT  (2) 

How  “in  sync”  are  your  software  systems  to  your  organizations  PDP  processes? 
Are  the  systems  supportive  to  how  your  org  creates  products? 

Highly  synchronized 
Somewhat  synchronized  (9) 

Somewhet  unsynchronized  (3) 

Highly  unsynchronized  (1) 

No  response  (2) 

Very  herd  to  find  informetion  when  needed  Too  much  dete  stored  ell  over. 

Are  formalized  “work  flow"  based  systems  used  to  support  your  PDP  (Y/N)? 

Yes  (7) 

No  (4) 

No  response  (4) 

If  Yes - 

How  much  of  your  PDP  is  modeled/embedded  in  work  flow  processes  (give 
percentage)? 

90%  or  more  (2) 

50%  or  more  (3) 

No  idea  (2) 

Is  work  flow  processing  used  as  a  mechanism  to  aid  in  decision-making 
activities? 

Yes  (5) 

No  (2) 

Can  you  describe  decisions  in  your  PDP  where  work  flows  used  as  a  mechanism 
for  decision-making  “is  a  good  fit"  (for  the  tool)? 

Sending  information  to  menufacturing 
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Design  raviaw 

Engine  a  ring  chang  a  reviaws 

Can  you  describe  decisions  in  your  PDP  where  work  flows  used  as  a  mechanism 
for  decision-making  are  NOT  a  “good  fit"  (for  the  tool)? 

No  or  no  response  across  tha  board. 

Please  describe  the  use  of  the  Internet  and  Web-based  technologies  in  your 
product  development  activities. 

PDM  systams  ara  Wab  based,  only  accassibla  via  intranet 

What  types  of  data  is  considered  a  “product"  of  your  product  development 
process?  How  is  it  managed? 

End  parts  supplied  to  custom ars 
Concepts  and  studies 
Raleasad  softwara 

Data  managed  in  internal  and  customer  systems  such  as  iMan,  Metaphase,  and  VPN 


Decision  Making,  Data,  and  Integration 

At  a  high  level,  please  describe  the  types  (or  examples)  of  decisions  your 
organization  makes  to  support  product  development.  How  are  decision  typically 
made  -  who  is  involved,  what  kind  of  data  is  used  in  the  decision  making,  what 
are  the  results,  and  what  influences  the  decisions 

Suggested  sheet  metal  anvironments  such  as  tola  ranees,  radius,  construction,  and  gaps 
Whathar  to  bid  on  a  projact  or  not 
Releasing  da  signs  to  manufacturing 

How  are  decisions  “captured"  in  your  organization?  What  kind  of  information 
related  to  decisions  is  actually  captured  as  part  of  or  with  the  decision  (i  e.  what 
data  was  used  to  help  make  the  decision)? 

Not  aware  of  any  specific  captunng  procassas 
Soma  FEA  benchmarking ,  target  values  fro  custom  ars 
Decisions  made  in  workflow  processes 

Do  you  think  there  is  value  in  capturing  information  that  was  used  to  help  or 
influence  a  decision? 

Yas  (14) 

No  response  (1) 

What  types  of  decisions  would  this  type  of  information  be  useful  for? 

Things  gone  right,  things  gone  wrong 
Cost  avoidanca 
Timing  issuas  and  delays 
Product  delivary  issues 
Cost  reductions 

How  would  you  rate  your  organization’s  ability  to  capture  information  supporting 
a  decision  (High/Medium/Low)? 
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Low  (8) 

Medium  (3) 

High  (2) 

No  response  (2) 

Does  your  organization  promote  “lessons  learned”?  If  so,  how?  Do  you  think  it 
is  effective  in  your  organization? 

Yes  (9) 

No  (4) 

No  response  (2) 

We  sey  we  do,  but  reelly  do  not 
Current  methods  ere  progrem  reviews 
Project  notebooks 
After  Action  Reviews 

Does  your  organization  reuse  information  from  past  decisions  in  current 
decision-making  activities? 

No  (10) 

Yes  (3) 

No  response  (2) 

Lessons  teemed  in  project  notebooks 

Please  take  a  moment  to  identify  a  PDP-based  decision-making  activity  that  you 
are  familiar  with  and  can  describe  in  detail  where  the  use  of  past  decision  history 
and  information  could  influence. 

Understanding  the  onginel  requirements/needs  end  mekmg  sure  es  the  need  edjusts,  the 
decision  does  es  welt  (mentioned  e  couple  times) 

Using  FEA  end  other  inputs  consistently 
Problems  with  designs 
Poorly  executed  concepts 


With  the  detailed  decision  in  mind3  now  put  yourself  in  the  position  of  a  new 
manager/engineer  who  must  make  this  decision  Where  would  you  tell  that 
person  to  gain  knowledge  to  make  a  decision? 

Understend  how  requirement  chenges  impact  decisions 
Attempt  to  locete  es  much  similer  dete  es  possible  for  e  decision 
Know  where  to  find  informetion  to  meke  decisions 

What  kind  of  “external”  data  is  used  in  your  organization’s  product  development 
activities  (primarily  decision-making  related)? 

Very  little,  except  in  cnsis  situations 
Acedemic  studies 

What  (or  how)  does  your  organization  get  this  external  data  -  is  there  too  much 
reliance  on  just  what  individuals  know? 

Yes  (9) 

Systems  very  unregulated  et  finding  informetion,  uneble  to  seerch 
Too  much  uwho  you  know",  not  enough  knowing  where  to  find  data 
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Despite  advances  in  computer  technology,  bringing  products  to  market 
remains  a  complex  activity  rife  with  uncertainty.  In  particular,  it  is  within  the 
concepting  phase  of  the  product  development  cycle  where  information  used  to 
make  decisions  is  at  its  most  nebulous  Organizations  invest  resources  into 
collaboratively-oriented  computer  systems  aimed  at  providing  decision  makers 
access  to  a  comprehensive  data  set,  yet  may  not  be  experiencing  full  potential 
from  the  environment. 

One  aspect  of  the  organizational  data  set  used  to  support  concept- 
oriented  decision  making  is  insight  gained  from  past  activities,  sometimes 
referred  to  as  "lessons  learned"  Understanding  the  impact  of  a  decision 
becomes  valuable  as  resulting  events  are  derived  over  time.  By  leveraging 
aspects  of  past  decisions  linked  with  original  needs  and  subsequent  outcomes,  a 
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compelling  narrative  can  be  extracted  from  the  historical  data  set  to  benefit 
decision  makers.  In  practice,  most  computer  data  management  systems  are  not 
equipped  by  design  or  in  use  to  efficiently  capture  elements  from  past  decisions 
Therefore,  optimizing  the  technology  environment  supporting  concept 
development  becomes  important  to  promote  efforts  to  reduce  uncertainty  in 
decision  making.  This  research  provides  a  framework  by  which  a  Computer 
Supported  Cooperative  Work  (CSCW)  environment  can  be  effectively  deployed 
and  used  to  support  decision  making  in  the  concept  development  environment. 
The  goal  is  to  provide  a  concise  set  of  information  to  end  users  combining 
decision-oriented  data  with  relevant  artifacts  to  reduce  uncertainty  or  influence 
outcomes 
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